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Abstract 

The  Anti-Ballistic  missile  Laser  (ABL)  Project  is  committed  to  defense  against 
attack  from  enemy-launched  Theater  Ballistic  Missiles  using  an  airborne  laser  platform  to 
disable  an  enemy  missile  in  the  boost  phase  of  launch.  Wielding  a  laser  of  this  power  and 
scope  requires  that  no  collateral  damage  be  caused  by  laser  energy  which  may  escape 
from  the  theater  of  engagement.  The  most  likely  track  of  such  a  laser  would  pose  a 
significant  threat  to  space-based  assets. 

The  Predictive  Avoidance  algorithm  is  designed  to  predict  the  path  of  a  given 
laser  firing  sequence,  and  perform  real-time  forecasting  of,  cind  deconfliction  with,  the 
ephemerides  of  a  given  set  of  satellites.  The  primary  goal  is  to  establish  the  theoretical 
framework  of  this  algorithm.  The  secondary  goal  of  this  thesis  is  to  develop  a  modular 
software  package  that  can,  with  minor  modifications,  be  incorporated  into  the  fire-control 
system  of  ABL  to  perform  real-time  forecasting  within  given  time  and  error  budgets. 
This  software  takes  the  form  of  a  Preprocessor,  that  filters  the  active  satellites  to 
determine  which  satellites  are  in  view,  and  the  Main  Processor,  which  analyzes  the 
satellites  that  are  in  view.  The  Main  Processor  determines  whether  any  of  the  satellites  in 
view  will  intersect  the  laser  beam  while  it  is  illuminating  a  target. 
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ANTI-BALLISTIC  MISSILE  LASER  PREDICTIVE  AVOIDANCE  OF  SATELLITES: 

THEORY  AND  SOFTWARE  FOR 
REAL-TIME  PROCESSING  AND  DECONFLICTION  OF 
SATELLITE  EPHEMERIDES  WITH  A  MOVING  PLATFORM  LASER 

I.  introduction 

The  Anti-Ballistic  missile  Laser  (ABL)  Project  is  committed  to  defense  of  the 
United  States  and  its  allies  against  attack  from  enemy-launched  Theater  Ballistic  Missiles 
(TBMs).  The  ABL  is  a  system  which,  when  deployed,  will  be  housed  in  a  Boeing  747- 
400F  airframe.  It  will  fly  at  a  cruising  altitude  of  roughly  12.9  km  (Forden,  Sept  97), 
above  most  cloud  cover.  From  this  altitude,  it  will  acquire  target  missiles  through  an 
active  tracking  system,  attempting  to  destroy  the  missile  in  its  boost  stage,  where  it  is 
most  vulnerable. 

1.1  ABL  Strategy 

The  ABL  will  fly  above  the  cloud  deck,  and  will  most  likely  travel  in  an 
elongated  figure-eight  flight  path.  The  long  axis  of  the  figure-eight  will  be  perpendicular 
to  the  expected  direction  of  the  missile  launch,  to  ensure  the  smallest  focal  radius  to  the 
possible  targets  for  a  given  period  of  time. 

1.1.1  Laser  Systems 

The  ABL  will  actually  be  comprised  of  four  independent  laser  systems.  The  first 
of  these  systems,  the  Active  Ranging  System  (ARS)  laser,  is  a  frequency  modulated 
continuous-wave  carbon  dioxide  laser.  It  operates  at  a  relatively  low  power  (200  Watts) 
at  a  wavelength  of  approximately  11.15  |im.  Its  purpose  is  solely  to  actively  scan  for  a 


target.  The  second  laser,  the  Track  ELluminator  Laser  (TILL)  is  a  kilowatt-class  Yb:Yag 
laser  estimated  to  operate  at  a  wavelength  of  approximately  1.03  micrometers.  After  a 
target  has  been  located  with  the  ARS,  it  will  be  illuminated  with  the  TILL  to  begin  active 
tracking  of  the  target.  The  third  laser  system,  the  Beacon  ILluminator  Laser  (BILL)  is 
also  a  kilowatt-class  laser  system.  It  will  be  composed  of  a  Nd:Yag  laser  with  a 
wavelength  of  approximately  1 .06  micrometers.  Shortly  after  the  TILL  has  begun  active 
tracking  of  the  Theater  Ballistic  Missile  (TBM),  the  BILL  will  be  turned  on  and  will  be 
used  to  provide  real-time  data  to  an  atmospheric  compensation  system  designed  to 
compensate  for  atmospheric  turbulence.  After  the  BELL  has  been  trained  and  locked  onto 
the  TBM,  the  final  laser  will  be  fired.  This  final  laser,  the  High  Energy  Laser  (HEL),  is  a 
Chemical  Oxygen-Iodine  Laser  (COIL)  that  will  operate  at  a  wavelength  of 
approximately  1.315  micrometers  (Forden,  Sept  97).  Its  power  is  estimated  by  the  author 
to  be  between  1-3  Megawatts. 


Table  1.1  The  Lasers  Aboard  the  ABL  Platform 


Device 

Wavelength 

Power 

Pulse  Type 

Aperture  Size 

ARS 

11.15  urn 

200  W 

FMCW 

8  inches 

TILL 

1.03  p^m 

KW  class 

5  KHz,  50  nsec 

30  cm 

BILL 

1.06  pm 

KW  class 

7.5  KHz,  50  nsec 

30  cm 

HEL 

1.315  pm 

1-3  MW 

CW 

150  cm 
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1.1.2  The  Predictive  Avoidance  Concept 

During  the  course  of  a  mission,  laser  energy  will  almost  certainly  escape  from  the 
target  area.  The  lasers  of  the  ABL  are  designed  for  long-distance  propagation,  being 
focused  in  a  fairly  narrow  beam.  This  means  that  even  at  great  distances,  escaping 
energy  from  these  lasers  may  pose  a  threat  to  any  inadvertent  targets  that  stray  into  the 
line  of  fire,  perhaps  far  downrange  of  the  targeted  missile.  The  exception  to  this  rule  is 
the  ARS,  which  is  a  fairly  low  power  laser  that  will  attenuate  quickly  within  the 
atmosphere.  For  this  reason,  the  ARS  is  not  considered  when  assessing  a  threat  to 
inadvertent  targets.  The  TILL,  BILL  and  especially  the  HEL,  however,  are  considered  to 
be  potentially  dangerous  to  downrange  assets.  But  what  assets  are  threatened?  The  ABL 
will  almost  certainly  be  firing  above  the  artificial  horizon  of  the  aircraft,  because  of  the 
nature  of  the  target  being  acquired.  Therefore  ground  assets  and  aircraft  are  not  at  great 
risk.  However,  satellites  are  at  risk.  They  can  conceivably  be  at  any  point  in  the  sky,  and 
can  be  extremely  sensitive  to  radiation  emanating  from  an  Earth-ward  direction.  Of 
particular  interest  are  Low-Earth  Orbiting  (LEO)  satellites  and  manned  platforms  that 
have  sensors  pointed  towards  the  Earth.  At  LEO  altitudes  the  lasers  aboard  the  ABL  can 
certainly  damage  these  sensitive  assets.  The  concept  of  Predictive  Avoidance  (PA)  is  to 
develop  a  strategy  whereby  the  targeted  missile  is  destroyed,  while  all  downrange 
satellites  are  spared  from  potentially  harmful  laser  radiation. 

1.1.3  Predictive  Avoidance  Strategy 

The  Beam  Control/Fire  Control  (BC/FC)  system  within  the  ABL  platform  is  a 
computer  that  controls  the  tracking  and  firing  of  the  ABL’s  four  lasers.  Among  the  many 
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tasks  of  the  BC/FC  is  to  pass  all  commands  given  by  the  user  of  the  system  through  an 
“engagement  filter”,  which,  among  other  things,  can  inhibit  the  firing  sequence  if  a 
dangerous  situation  (such  as  a  satellite  passing  through  the  lazing  arc)  is  detected 
(Leonard,  1998).  The  task,  therefore,  is  to  construct  a  piece  of  software  that  can  monitor 
the  locations  of  satellites  and  provide  satellite/laser  deconfliction  information  directly  to 
the  BC/FC  system.  This  “Predictive  Avoidance  Software  Package”  (PASP)  could  then 
be  run  just  prior  to  engaging  a  missile  to  ensure  that  no  satellites  are  forecasted  to  fall 
within  the  laser’s  path. 

1.2  The  Goal  of  This  Study 

The  primary  thrust  of  this  thesis  is  to  construct  a  reliable  real-time  predictive 
avoidance  algorithm  that  uses  inputs  as  they  would  exist  in  the  operational  environment 
of  the  ABL  platform  and  generates  outputs  that  directly  communicate  the  probability  of 
lazing  a  satellite  during  a  given  mission  with  known  mission  parameters.  A  second  goal 
of  this  study  is  to  produce  a  software  package  that  runs  this  predictive  avoidance 
algorithm  in  real-time.  This  software  package  is  designed  with  three  conflicting  (but 
important)  objectives.  The  first  objective  is  to  make  the  software  readily  understandable 
to  a  person  who  wishes  to  study  it  in  the  future.  This  software  is  designed  with  an 
agreement  by  Boeing  that  it  will  be  studied  and  at  least  partially  incorporated  directly  into 
the  BC/FC  of  the  ABL  platform.  Therefore,  to  ensure  a  smooth  incorporation  into  ABL, 
the  software  will  be  as  clear  and  non-ambiguous  as  possible.  The  second  goal  is  that  the 
software  be  fast.  It  is  estimated  that  the  predictive  avoidance  software  should  not  need 
more  than  0.5  seconds  to  fully  process  a  mission.  Therefore,  strategies  must  be  taken  to 
minimize  processing  time.  The  third  major  goal  for  the  PA  software  is  that  it  should  be 
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modular.  There  are  a  number  of  methods  that  are  used  within  this  software  that  may 
become  obsolete  or  deemed  inaccurate  by  ABL  engineers.  While  this  is  not  an  aspiration 
for  this  software,  it  would  be  foolish  to  not  plan  for  this  contingency.  Therefore  the 
components  of  this  software  package  should  be  highly  granular.  That  is,  the  tasks  should 
be  divided  into  as  small  of  chunks  as  possible.  It  should  also  have  clean,  strongly  defined 
interfaces  between  those  modules.  Of  these  three  goals  for  the  software, 
understandability  is  the  most  important.  There  are  many  cases  within  the  software  in 
which  a  fluid,  slow,  understandable  implementation  has  been  used  instead  of  a  speedier 
vague  implementation.  This  is  done  with  the  understanding  that  the  software  will  be 
reviewed  at  a  later  time,  when  any  “slow”  algorithms  may  be  supplanted  with  the 
software  engineer’s  choice  of  implementations. 

1.3  Method  of  Attack 

The  method  that  will  be  used  here  to  solve  the  Predictive  Avoidance  problem  is  to 

split  the  task  into  two  smaller  tasks,  which  we  shall  call  the  Anti-Ballistic  missile 

Laser/Predictive  Avoidance  (ABLPA)  Preprocessor,  and  the  ABLPA  Main  Processor. 

The  ABLPA  Preprocessor  will  handle  the  task  of  dissecting  the  list  of  satellite  objects 

provided  by  US  Space  Command,  and  determining  which  of  these  objects  are  in  view  of 

the  platform  during  the  operational  employment  of  the  laser.  The  ABL  Main  Processor, 

on  the  other  hand,  will  have  the  task  of  analyzing  the  “short”  list  of  satellite  objects  in 

view  (determined  by  the  Preprocessor),  and  performing  real-time  calculations  to  compare 

the  arc  of  the  laser  with  the  path  of  the  satellite.  It  will  be  the  Main  Processor  that  is 

executed  during  the  fire-sequence  of  ABL  to  determine  in  real-time  the  probability  of 

accidentally  lazing  a  satellite.  The  reason  that  the  PA  task  has  been  split  in  this  way  is 
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fairly  straightforward.  The  Main  Processor  must  execute  its  task  in  as  little  time  as 
possible,  because  it  is  run  as  part  of  the  BC/FC  sequence,  which  must  rapidly  acquire, 
track  and  laze  the  ballistic  missile  target.  If  there  are  fewer  targets  to  process  in  the  Main 
Processor  sequence,  it  will  execute  more  quickly. 
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II.  ABLPA  Preprocessor  Methodology 


As  mentioned  previously,  in  order  to  save  as  much  time  as  possible  within  the 
main  processor,  it  is  necessary  to  limit  the  number  of  satellites  that  are  processed.  The 
preprocessor  filters  satellite  ephemerides  to  find  only  those  satellites  that  may  possibly  be 
within  the  range  of  the  laser  platform  for  a  specified  time.  This  is  accomplished  in  two 
separate  tasks.  In  the  first  task,  the  preprocessor  must  locate  the  satellite  at  the  current 
local  time,  and  determine  whether  or  not  the  satellite  is  currently  in  view.  This  is  done 
with  the  help  of  an  ephemeris  time  propagator.  Satellite  General  Perturbations  propagator 
(SGP4)  developed  by  Air  Force  Space  Command  to  track  orbiting  objects.  The  second 
task  involves  determining  when  (if  ever)  the  satellite  will  come  into  view  of  the  platform. 
This  second  task  is  only  needed  if  the  satellite  is  not  in  view.  For  instance.  The  ABLPA 
Preprocessor  will  be  executed  at  regular  intervals,  but  the  possibility  exists  that  a  satellite 
may  fly  into  view  of  the  platform  after  the  Preprocessor  executes  but  before  the  next 
execution.  If  so,  this  satellite  must  also  be  included  on  the  “short”  list  of  objects  fed  to 
the  Main  Processor.  These  two  tasks,  and  the  methods  by  which  they  are  resolved,  are 
the  focus  of  this  chapter. 

2.1  Locating  the  Platform 

The  first  step  in  finding  the  location  of  the  satellite  with  respect  to  the  ABL 
platform  is  to  determine  where  the  platform  is,  and  in  what  coordinate  frame  its  position 
is  known.  In  general,  we  can  expect  to  receive  the  platform’s  position  in  terms  of  latitude 
(8),  longitude  (A,),  and  altitude  (h).  This  frame  of  reference  is  Earth  Centered  Earth  Fixed 
(ECEF),  and  rotates  with  the  Earth.  Unfortunately,  this  method  of  reference  does  not 
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lend  itself  easily  to  fixing  a  position  with  respect  to  a  satellite,  whose  coordinates  are 
most  often  given  in  the  Earth-Centered/Inertial  (ECI)  coordinate  frame.  Therefore  a  way 
must  be  found  to  transfer  the  platform’s  position  vector  from  the  ECEF  frame  to  the  ECI 
frame. 

2.2  Finding  6g 

Let  the  value,  0g,  represent  the  true  angle  between  the  Greenwich  Meridian  (that 
“moves”  with  the  Earth)  and  the  Vernal  Equinox,  or  First  Point  of  Aries,  which  is  a  point 
relatively  “fixed”  in  the  heavens.  This  value  is  important  because  it  provides  the  rotation 
angle  between  the  ECEF  coordinate  frame  and  the  ECI  frame. 

2.2.1  The  ECEF  frame 

Most  aircraft  reference  their  position  with  respect  to  the  Equator  (0°  latitude),  the 
Greenwich  Meridian  (0°  longitude),  and  their  height  above  sea-level.  This  reference 
system  provides  a  way  to  track  location  in  a  coordinate  frame  which  is  fixed  with  respect 
to  the  globe.  This  is  the  frame  in  which  the  ABL  platform  will  likely  reference  its 
position.  Both  coordinate  frames  use  the  Earth’s  polar  axis  as  one  reference  axis,  and  the 
equatorial  plane  as  the  reference  plain  in  which  the  other  two  reference  axes  lie. 
However,  the  ECEF  frame  rotates  with  the  Earth  using  the  line  from  the  center  of  the 
Earth  to  the  Greenwich  Meridian  as  its  second  reference  axis. 

2.2.2  The  ECI  Frame 

Because  the  Earth  is  “rotating”  in  space  with  respect  to  other  celestial  bodies,  the 
ECEF  frame  becomes  inconvenient  to  track  the  motions  of  satellites  that  orbit  the  Earth. 
A  new  frame,  the  ECI  frame,  is  adopted  to  track  these  motions.  This  frame  does  not 
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rotate  with  the  Earth,  but  rather  fixes  a  reference  axis  on  the  Vernal  Equinox,  also 
referred  to  as  the  First  Point  of  Aries.  This  provides  a  seemingly  more  absolute  fixed,  or 
“inertial”,  frame  with  which  to  measure  the  rotation  of  the  Earth  and  the  motions  of 
satellites. 

2.2.3  Frame  Conversion 

As  might  be  expected,  a  conversion  must  exist  between  these  two  frames  of 
reference  if  any  meaningful  correlation  between  the  motions  of  objects  in  these  two 
reference  frames  is  to  be  done.  6g  will  be  used  to  refer  to  the  rotation  angle  between 
these  two  coordinate  frames,  and  will  be  used  for  this  conversion.  Fortunately,  the  rate  of 
the  rotation  of  the  Earth  is  fairly  constant,  remaining  relatively  fixed  at  1  revolution  every 
23  hours,  56  minutes  and  4.09054  seconds  (American  Ephemeris  and  Nautical  Almanac, 
1980).  In  so  stating  this,  I  am  neglecting  the  gradual  deceleration  of  the  Earth’s  rotation, 
which  is  assumed  to  be  negligible  for  the  relatively  short  time  spans  with  which  we  will 
be  addressing  here.  Therefore: 

1  sidereal  day  =  23*3600  +  56*60  +  4.09054  =  86164.09054  sec  (2.1) 

The  Earth  rotates  at  the  rate: 

- - =  0.004178074622^  =  0.000072921 1585453—  =  0,  (2.2) 

86 164.09054 sec  sec  sec 

2.2.4  Absolute  Time 

Now  that  we  have  a  rotation  rate  of  one  coordinate  frame  with  respect  to  the 
other,  we  need  to  specify  the  amount  of  time  that  transpires  during  our  observations. 
Furthermore,  we  need  to  specify  a  starting  value  of  0g  in  order  to  propagate  its  value  into 
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the  future.  We  can  obtain  the  former  by  using  Modified  Julian  Time  (MIT),  which  is 

easily  mapped  to  Greenwich  Mean  Time  (GMT).  For  brevity,  I  will  not  discuss  the  time 

mapping  algorithm  here,  but  will  refer  the  reader  to  the  software  modules  written  in 

conjunction  with  this  thesis.  The  module  “TimeModules.c”  performs  the  conversion 

between  GMT  and  MJT  (Numerical  Recipes  in  C,  1990).  These  modules  can  be  found  at 

the  end  of  this  paper.  We  can  further  obtain  a  starting  point  of  9g  by  referencing  the 

American  Ephemeris  and  Nautical  Almanac(1980)  and  taking  any  value  of  0g  which  is 

paired  with  its  corresponding  Julian  time.  For  example; 

Date:  December  1,  1980 

Julian  Date:  2444574.5 

Modified  Julian  Date:  4574.5 
0g:  4  hrs  40  min  1.299  sec 

=[(4*3600)+(40*60)+(  1.299)]  *  [0.004 166666667deg/sec] 

=  70.0054124999  degrees 
=  1.22182494234  radians 

It  is  interesting  to  note  that  the  position  is  referenced  in  terms  of  Hours,  Minutes  and 
Seconds  (HMS),  rather  than  degrees  within  the  Almanac.  Transformation  between  HMS 
and  degrees  is  relatively  straightforward.  There  are  24  hours  in  360  degrees.  Therefore: 

lsec  = - 360deg - =  0.004166666667^  (2.3) 

(24/ir^*3600— ) 
hr 

Notice  that  we  do  not  use  the  sidereal  day  (23  hrs,  56  min,  4.09054  sec)  to  translate  these 
two  measuring  systems,  because  the  arc  of  the  angle  is  measured  in  a  complete  24  hour 
rotation,  not  according  to  the  true  sidereal  day. 

Using  this  method,  and  the  starting  reference  position,  0g  ean  be  caleulated  for 
any  time  in  the  future  by  propagating  forward  using  the  angular  velocity  of  0g, 
0.004178074622  deg/sec.  Any  anomalies  in  the  propagation,  such  as  the  gradual 
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deceleration  of  the  Earth’s  rotation,  precession,  etc.,  can  be  minimized  by  picking  a 
reference  time  closer  to  the  propagation  time,  lessening  the  number  of  revolutions  seen  in 
the  propagation. 


2.2.5  Sample  6g  Calculation 

In  this  section,  the  truth  of  the  above  sections  will  be  demonstrated  by  showing 
that  a  value  for  0g,  propagated  from  a  reference  point,  matches  actual  observations  to  a 
relatively  high  precision  (American  Ephemeris...l980).  The  date  I  will  choose  to  find 
will  be  midnight,  December  31®‘,  1980.  The  reference  position  and  time  will  be  taken  as 
one  month  prior,  midnight,  December  1®',  1980: 


THE  REFERENCE  DATE: 

Reference  Date  =  December  1 , 1 980 
Reference  Time  =  0  hr  0  min  0  sec  (midnight) 

ReferenceJulianDate  :=  2444574.5 
RefModJulianDate  ReferenceJulianDate  -  2440000 

RefModJulianDate  =4.5745*  10^ 

GgHours  :  =  4 
GgMinutes  :  =  40 
OgSeconds  :  =  1 .299 

DegreesPerSecond  :  =  — — 

24 -.3600 

DegreesPerSecond  =4.166666666666667*10  ^ 

RefOgDegrees  :  =  ( GgHours  -3600  +  GgMinutes  60  +-  GgSeconds  )  -DegreesPerSecond 
RefGgDegrees  =  70.00541249999999 


We  will  use  MathCad  Version  7  to  propagate  the  angle  of  0g  which  occurs  at  midnight  on 
December  31,  1980,  30  days  later.  Notice  that  the  reference  date  must  be  used  in  the 
calculation.  Also  notice  that  the  original  value  for  0g  is  the  total  amount  traversed,  and 
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must  be  divided  modulo  360  degrees  to  obtain  the  true  value  of  0g. 

PROPAGATION  DATE 

Propagation  Date  =  December  31 , 1 980 
Propagation  Time  =  0  hr  0  min  0  sec  (midnight) 

PropJulianDate  :  =  2444604.5 

PropModJulianDate  :  =  PropJulianDate  -  2440000 

3 

PropModJulianDate  =  4.6045  *10 

PropagationTime  -(PropModJulianDate  —  RefModJulianDate  ) -24 -3600 

PropagationTime  =2.592»10^ 

r.  .  360 

PropagationRate  :  = - 

(23  •3600  +  56*60  4-4.09054) 

PropagationRate  =  4.178074621850468  *10  ^ 

GgDegrees  ;  -  Ref  OgDegrees  +  PropagationTime  -PropagationRate 
OgDegrees  =  1.089957483233642  •lO'^ 

Prop  OgDegrees  :  =  mod  ( OgDegrees  ,  360 ) 

Prop  OgDegrees  =  99.57483233641506 

The  Almanac  gives  its  observation  of  0g  for  the  propagation  date  as  follows: 

THE  TRUE  ANGLE  FOR  THE  PROPAGATION  DATE  GIVEN  BY 
THE  AMERICAN  EPHEMERIS  AND  NAUTICAL  ALMANAC: 

Almanac  Date  =  December  31 , 1 980 
Almanac  Time  =  0  hr  0  min  0  sec  (midnight) 

ReferenceJulianDate  :=  2444604.5 

RefModJulianDate  :  =  ReferenceJulianDate  ~  2440000 

RefModJulianDate  =4.6045*10^ 

OgHours  :~6 
OgMinutes  :=38 
OgSeconds  17.959 
360 

DegreesPerSecond  :  = - — 

24*3600 

-3 

DegreesPerSecond  =  4. 16666666666666710 

Almanac  OgDegrees  (OgHours  *3600+ OgMinutes  *60+ OgSeconds  )  *DegreesPerSecond 
Almanac  OgDegrees  =  99.57482916666666 
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Finally,  the  propagated  angle  must  be  compared  with  the  observation  from  the  Almanac 
to  judge  the  accuracy  of  the  algorithm. 


DIFFERENCE  BETWEEN  PROPAGATION  ANGLE  AND  ALMANAC  ANGLE: 

BgDegreeDifference  :=Prop0gDegrees  -  Almanac  BgDegrees 
BgDegreeDifference  =3.169748396203431*10  ^ 


From  this,  we  can  see  that  in  the  period  of  30  days,  0g  can  be  accurately  predicted  to  at 
least  0.0005%  error  from  the  true  angle.  This  indicates  a  predictable  accuracy  below  10 
meters  at  the  Earth’s  surface  over  a  time  propagation  of  30  days. 

2.2.6  Accuracy 

There  are  some  problems  with  predicting  0g  too  far  into  the  future.  Natural 
occurring  anomalies  that  are  difficult  to  model  will  invariably  affect  the  true  angle 
between  the  Greenwich  Meridian  and  the  Vernal  Equinox.  Precession,  nutation  and  the 
Chandle  wobble  of  the  Earth’s  rotation  axis,  all  of  which  cause  the  Earth  to  “wobble”  on 
its  axis  rather  than  cleanly  spin,  will  affect  the  rate  of  angular  separation  slightly.  These 
effects  are  extremely  difficult  to  model,  and  could  be  the  topic  of  another  study.  They 
can  be  mitigated,  however,  by  choosing  reference  date  that  is  close  to  the  mission  date. 
Very  little  anomalous  precession  occurs  within  one  week.  And  the  closer  the  date,  the 
more  aecurate  a  propagation  of  0g  will  be.  It  is  probably  unwise  to  choose  a  reference 
date  that  is  more  than  a  couple  months  old,  as  new  references  are  constantly  being  made. 
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and  reference  dates  might  easily  be  ignored,  growing  ever  more  out  of  date,  if  their 
update  is  not  made  a  standard  practice. 


2.3  Finding  the  Platform  in  the  ECI  frame 


All  that  remains  for  finding  the  coordinates  of  the  platform  in  the  ECI  frame  is  to 
find  the  coordinates  of  the  platform  in  the  ECEF  frame,  and  then  do  a  single  rotation 

using  the  value  of  0g  that  is  determined  according  to  the  methods  described  previously. 

R®+h=  Radius  of  the  Earth  +  Altitude  of  the  Aircraft 
X  =  ECEF  X  coordinate  of  platform 
y  =  ECEF  Y  coordinate 
z  =  ECEF  Z  coordinate 
\  =  Degrees  longitude 

5  ==  Degrees  latitude 


►  "^ECEF 


Figure  2.1.  Locating  Platform  In  ECEF  Frame 


Figure  2.1  illustrates  the  conversion  from  latitude,  longitude  and  altitude  to  X,  Y  and  Z  in 
the  ECEF  frame.  From  the  figure  it  can  easily  be  seen  that: 

a  =  iR^+h)cos(5)  (2.4) 
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and: 


X  =  (a)  cos(A) 
y  =  (a)sin(A) 
z  =  (Ji^+h)sin(S) 


(2.5) 

(2.6) 
(2.7) 


From  these  relations,  it  is  seen  that  the  coordinates  of  the  platform  in  the  ECEF  frame 
are: 


Recef  = 

(R  e  +h)  cos(S)  cos(A) 
(R  e  +h)  cos(S)  sin(A) 

X 

y 

(Re+h)sin(S) 

z 

To  translate  this  position  vector  into  the  ECI  coordinate  frame,  we  use  a  rotation  matrix 
about  the  Z  axis,  using  0g  as  the  rotation  angle: 


Rec/  = 


cos  ft 
sin  ft 


0 


-sin  ft 
cos  ft 
0 


0 

0 

1 


•  Recef 


(2.9) 


From  here,  we  also  obtain  the  satellite’s  position  vector  by  using  a  time  propagator  to 
determine  the  position  at  the  current  time.  Fortunately,  there  are  already  ephemeris 
propagators  in  existence,  and  this  project  will  use  SGP4  Version  C3.01  developed  by  Air 
Force  Space  Command. 


2.4  Locating  the  Satellite 

It  should  be  noted  here  that  SGP4  is  used  because  a  better  propagator  could  not  be 
found  in  the  public  domain.  SGP4  only  models  general  perturbations,  and  therefore  will 
not  be  very  accurate  when  propagating  a  satellite  ephemeris  over  long  periods  of  time. 
Unfortunately,  this  project  has  limited  resources,  and  therefore  cannot  branch  off  into 
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intensive  testing  of  the  propagator  that  is  used.  This  task  could  be  the  subject  of  a  thesis 
within  itself,  because  accuracy  depends  upon  many  factors  including  the  type  of  orbit,  the 
solar  weather,  the  time  of  propagation  and  so  on.  Almost  all  of  the  errors  introduced  into 
SGP4’s  propagation  estimates  can  be  significantly  reduced  by  limiting  the  amount  of 
time  over  which  the  propagation  occurs.  This  is  done  by  ensuring  that  the  Two-Line 
Element  (TLE)  sets  used  as  inputs  to  the  propagator  are  timely,  preferably  less  than  24 
hours  old.  This  will  ensure  that  the  propagator  on  which  this  project  relies  will  not  have 
to  propagate  over  a  large  amount  of  time,  each  hour  of  which  increases  the  position  error. 

2.5  Use  of  a  Time  Propagator 

Both  the  ABLPA  Preprocessor  and  the  ABLPA  Main  Processor  depend  upon 
fixing  the  current  position  and  velocity  vectors  of  a  satellite  through  the  means  of  a  time 
propagator.  The  accuracy  of  the  propagator  has  a  direct  correlation  to  the  effectiveness 
of  these  programs.  For  instance,  if  the  satellite’s  position  can  only  be  estimated  within  a 
first  sigma  error  of  +  500  kilometers,  then  the  Main  Processor  will  effectively  see  that  a 
satellites  error  cross  section  covers  a  significant  field  of  view,  making  it  extremely 
difficult  to  find  a  window  in  which  to  fire.  As  mentioned  previously,  this  error  can  be 
reduced  by  limiting  the  time  through  which  position  propagation  occurs.  Error  can  also 
be  reduced  by  finding  a  better  propagator  that  handles  special  perturbations.  As  of  the 
writing  of  this  thesis.  Air  Force  Space  Command  is  working  on  the  completion  of  just 
such  a  propagator.  It  is  estimated  that  this  Special  Perturbations  (SP)  propagator  will  be 
completed  by  the  summer  of  1999.  This  propagator  may  find  suitable  use  as  a  substitute 
for  SGP4  in  both  the  Preprocessor  and  the  Main  Processor.  It  may,  however,  prove  to  be 
too  complicated  for  use  in  the  Main  Processor.  The  SP  propagator,  while  more  accurate 
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than  SGP4,  will  almost  certainly  prove  to  be  far  more  complicated.  It  will  require  more 
input  parameters,  and  will  take  longer  to  execute.  This  is  not  a  problem  for  the 
Preprocessor,  as  the  Preprocessor  is  not  narrowly  constrained  by  the  amount  of  time  in 
which  it  needs  to  run.  However,  the  Main  Processor  needs  to  execute  quickly,  in  “real¬ 
time”.  If  the  SP  propagator  requires  an  extra  0.1  seconds  to  run,  this  translates  into  an 
extra  10  seconds  minimum  for  the  Main  Processor  running  with  a  100-satellite  TLE  set. 
This  is  clearly  unacceptable,  as  there  cannot  be  a  10  second  lag  in  the  fire  control  system. 
Therefore  any  replacement  for  SGP4  will  be  required  to  pass  this  hurdle. 


2.6  Comparison  of  Satellite  to  Platform  Position  Vector 

Now  that  we  know  R,  the  position  vector  of  the  platform  in  the  ECI  frame,  and  r, 
the  position  vector  of  the  satellite  in  the  ECI  frame  obtained  from  SGP4,  we  can  compare 
the  two,  looking  to  see  whether  the  satellite  crosses  the  artificial  horizon  of  the  platform. 
This  can  be  done  by  finding  D,  representing  the  component  of  r  in  the  R  direction: 

D  =  fsa,~^  (2.10) 

|/?.c| 

It  is  then  a  simple  matter  to  compare  the  magnitude  of  D  with  the  magnitude  of  R.  If  the 


Figure  2.2.  Illustration  of  the  Comparison  Between  R  and  r. 
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magnitude  of  D  is  greater  than  the  magnitude  of  R,  then  the  satellite  must  be  above  the 
artificial  horizon  of  the  platform,  and  is  therefore  in  view. 

2.7  Evaluating  Time-to-Rise 

Thus  far,  it  has  been  determined  whether  or  not  the  satellite  is  in  view  of  the 
platform,  but  it  has  not  been  determined  if  the  satellite  might  appear  above  the  horizon  at 
a  later  point  in  time.  We  are  interested  in  how  long  the  satellite  takes  to  cross  the  horizon 
because  there  is  a  slice  of  time  after  the  Preprocessor  runs  when  a  satellite  could  rise  and 
not  be  noticed  (until  the  next  run  of  the  Preprocessor).  Therefore,  we  would  like  to 
isolate  those  satellites  that  are  due  to  rise  before  the  next  run  of  the  Preprocessor,  so  that 
these  satellites  can  also  be  included  in  the  list  sent  to  the  Main  Processor.  To  do  this  is 
apparently  very  simple.  It  is  fairly  easy  to  approximate  the  rate  of  change  of  the 
magnitude  of  the  D  vector  discussed  earlier  and  compare  the  change  in  D  to  the  Time 
Until  the  Next  Run  (TUNR).  Doing  so  should  reveal  a  fair  estimate  of  whether  or  not  the 
satellite  is  due  to  rise  before  the  next  run  of  the  Preprocessor.  But  there  is  a  small 
problem.  There  may  be  a  case  when  the  satellite  never  rises.  Such  is  the  case  when  the 
platform  is  at  the  north  pole  and  the  satellite  is  in  an  equatorial  orbit.  This  is  also  the  case 
when  then  platform  is  on  the  equator  and  90  degrees  from  a  polar  orbiting  satellite.  In 
fact,  there  are  many  cases  like  this  when  the  rate  of  change  of  D  is  not  exactly  applicable 
to  our  analysis,  because  the  satellite  does  not  move  toward  or  away  from  the  platform  in 
the  short  time  under  consideration.  The  solution  to  this  problem  is  to  weed  out  all 
ephemerides  that  never  cross  the  artificial  horizon  plane  of  the  platform  before  we 
evaluate  the  time  to  rise  of  the  satellite. 
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2.8  Ephemeris  Clipping 

The  idea  of  the  Ephemeris  Clipping  Algorithm  (ECA)  is  fairly  straightforward. 
The  ECA  simply  throws  out  all  satellite  ephemerides  that  do  not  cross  the  artificial 
horizon  plane  in  the  current  orbit.  Thus,  in  the  case  of  Figure  2.3,  Ephemeris  1  would  be 
discarded  while  Ephemeris  2  will  be  further  evaluated. 


Figure  2.3.  Ephemeris  Clipping  Illustration 


It  is  important  to  note  that  this  algorithm  only  evaluates  a  satellite  in  its  current  orbit,  and 
does  not  propagate  the  ephemeris  in  time.  Therefore  the  orbital  elements  that  are  used  to 
evaluate  this  orbit  must  be  propagated  (also  using  SGP4)  to  the  current  time.  It  is 
therefore  assumed  that  the  ephemeris  does  not  change  significantly  in  the  time  between 
runs  of  the  Preprocessor.  Although  precession  of  the  Earth  may  change  the  attitude  of  the 
platform  with  respect  to  the  satellite  slightly  in  this  time,  the  variations  will  be  slight  if 
the  time  between  runs  is  kept  below  5  minutes. 
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2.8.1  Run  Intervals 


The  preprocessor  is  designed  to  run  at  given  intervals,  processing  a  new  set  of  “at- 
risk”  satellites  during  each  interval.  The  interval  time  should  be  long  enough  so  that  the 
preprocessor  can  easily  process  all  ephemerides  which  are  fed  to  it,  and  still  short  enough 
so  that  it  can  eliminate  a  majority  of  the  satellites  which  will  not  be  seen  during  the 
interval.  For  example,  picking  an  interval  of  one  second  may  not  be  wise,  because  the 
preprocessor  may  not  be  able  to  run  through  the  enormous  amount  of  data  in  that  time 
frame.  Furthermore,  picking  an  interval  time  of  90  minutes  may  not  be  very  beneficial, 
because  many  Low-Earth  Orbiting  (LEO)  satellites  have  periods  of  roughly  90  minutes. 
Therefore  if  a  satellite  is  still  an  hour  away  from  being  visible,  it  will  still  have  to  be 
looked  at  by  the  Main  Processor  during  the  fire  sequence.  For  the  purposes  of  this  study, 
5  minutes  will  be  used  as  a  nominal  time  interval.  Thus,  the  preprocessor  will  generally 
use  the  current  time  as  the  start  of  the  processing  time  interval,  and  the  current  time  plus 
5  minutes  as  the  end  of  the  processing  interval.  This  will  mean  that  the  preprocessor 
must  be  run  every  5  minutes  at  a  minimum,  but  may  be  run  more  often,  if  desired. 

2.8.2  Ephemeris  Clipping  Algorithm 

The  geometry  of  the  plane-clipping  problem  is  illustrated  in  Figure  2.4.  For  each 
satellite  being  evaluated,  we  are  given  as  inputs  the  orbital  elements  of  the  satellite  and 
the  time  interval  we  are  evaluating.  Our  goal  is  to  find  whether  or  not  the  satellite  crosses 
the  platform’s  plane  of  view.  As  a  beginning,  the  minimum  distance  d,  between  the 
platform  and  the  satellite  orbit  needs  to  be  determined.  This  is  logically  the  line  that 
forms  a  right  angle  with  the  orbit  plane  when  drawn  from  the  platform  to  the  orbit  plane. 
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6g  =  Degrees  between  Greenwich  Meridian  and  Vernal  Equinox 
oH-v  =  Argument  of  Perigee  +  the  True  Anomaly  of  the  satellite 
’P  =  Angle  between  ascending  node  of  satellite  and  the  platform 
y  =  Vernal  Equinox  (First  Point  of  Aries) 
d  =  Closest  pass  of  the  satellite  orb 
to  the  platform 
Degrees  longitude 


X 

S 

Q 


of  the  platform 
=  Degrees  latitude  of 

the  platform  ' * 

■  Right  Ascension 
of  the  satellite 
-  Inclination  of 
the  satellite 


Satellite  Orbit 


Greenwich 

Meridian 


Figure  2.4.  Preprocessor  Spherical  Geometry  Illustration 


The  two  spherical  triangles  illustrated  in  Figure  2.4  are  used  to  determine  d  in  degrees. 
From  the  figure,  it  can  be  seen  that  T'  represents  the  spherical  angle  from  the  ephemeris 
right  ascension  to  the  platform.  Using  the  spherical  right  triangle  formulae  the  length  of 
'P  can  be  determined  by: 

cos('P)  =  cos(<5)cos(f2-0g  -  A)  (2.11) 

Once  'P  has  been  found,  oc,  or  the  angle  between  'P  and  the  equator,  is  easily  found  with 
the  equation: 

cos(a)  =  tan(Q  -Bg-X)  cot('P)  (2. 12) 

The  angle  between  T'  and  the  ephemeris  propagation  direction  is  denoted  as  p.  As  shown 

in  the  following  examples,  the  method  for  finding  p  will  differ  depending  upon  location. 
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Figure  2.5.  Northern  Hemisphere, 
Prograde  Orbit  Cases 


2.8.3  Finding  Beta 


Unfortunately,  P  cannot  be  found  with  a 
single  equation.  As  a  matter  of  fact,  it  must  be 
found  by  looking  at  twelve  individual  geometric 
cases  which  serve  to  describe  the  relationship 
between  p,  a,  and  i. 

The  relationship  is  not  a  trivial  one.  It  is 
governed  by  the  hemisphere  of  the  Earth  (northern 
or  southern)  in  which  the  platform  lies,  the  slope 
of  the  orbit  (prograde  or  retrograde),  and  the 
position  of  the  platform  with  respect  to  the 
ephemeris  plane. 

The  first  three  cases  deal  with  the  possibility  that 
the  platform  is  in  the  northern  hemisphere,  and  the 
inclination  of  the  satellite  orbit  is  less  than  90 
degrees  (a  prograde  orbit).  As  the  graphical 
depiction  shows,  P  can  be  three  different  values, 
depending  upon  where  the  platform  lies  with 
respect  to  the  ephemeris  path.  For  instance,  in 
Case  1, 

0<{a  +  p)<90 

p=a  +  i  (2.13) 
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Northern 
Hemisphere 
Retrograde  orbit 
90<(a  +  i)<180 
p  =  180  -  a- i 


Likewise  in  Case  2: 

90<(a  +  z)^180 
p  =  m-a-i 


and  in  Case  3: 

180  <(«  +  /•)<  270 
P=a  +  i-m 


(2.14) 


(2.15) 


Case  5 
Northern 
Hemisphere 
Retrograde  orbit 
180<(a  +  i)<270 
p=  (a  +  I)-180 


While  cases  1  to  3  deal  with  a  prograde  orbit,  cases  4 
to  6  describe  the  relationship  between  a  platform  in 
the  northern  hemisphere  and  a  satellite  with  a 
retrograde  orbit.  One  might  be  tempted  to  jump  to 
the  conclusion  that  finding  P  would  be  the  same  as  in 
cases  1  to  3,  however,  as  can  be  seen  in  Figure  2.6, 
the  relationship  is  not  the  same.  In  Case  4,  where 


Case  6 
Northern 
Hemisphere 
Retrograde  orbit 
270<(a  +  i)<360  ( 
P=  360-(a  +  I)  = 


the  platform  is  located  below  the  retrograde  orbit  and 
above  the  equator: 

90  <(«  +  /)<  180 

p  =  m-a-i  (2.16) 

Similarly,  in  Case  5: 

180<(a  +  z)<270 

p=a  +  i-m  (2.17) 

And  in  Case  6: 


270  <  (a +  0^360 
p  =  360-a-i 


Figure  2.6.  Northern  Hemisphere, 
Retrograde  Orbit  Cases 


(2.18) 


Southern  Hemisphere 
Prograde  orbit 
90  <  (a  -  i)  <  0 


Just  as  there  are  six  possible  configurations  in  the 
northern  hemisphere,  there  are  also  six 
configurations  in  the  southern  hemisphere,  three  for 
prograde  orbits  and  three  for  retrograde.  Cases  7  to 
9  illustrate  the  possible  scenarios  for  a  platform  in 
the  southern  hemisphere  with  a  prograde  satellite 


Case  8 

Southern  Hemisphere 
Prograde  orbit 
0<(a-i)<90 
P  =  a-i 


orbit.  For  Case  7: 


-90  <(«-/)<  0 
P  =  i  — a 


For  Case  8: 


0<  (a-i)<90 
P  =  a-i 


And  for  Case  9: 


(2.19) 


(2.20) 


Case  9 

Southern  Hemisphere 
Prograde  orbit 
90<(a-i)<180 
P  =  180-fi-a 


9O<(a-0^18O 
p  =  m  +  i-a  (2.21) 

The  last  three  cases  illustrate  the  possibilities  in  the 
southern  hemisphere  combined  with  a  retrograde 
orbit.  For  Case  10: 

-180  <  (a- 0^-90 
p  =  m+a-i  (2.22) 


Figure  2.7.  Southern  Hemisphere, 
Prograde  Orbit  Cases 


For  Case  11: 


-90<  (a-i)<0 
P  =  i-a 


(2.23) 


Case  10 

Southern 
Hemisphere 
Retrograde  orbit 
-180<(a-i)<-90 
P=  180  +  a-i 


Case  11 

Southern  Hemisphere 
Retrograde  orbit 
-90  <  (a  -  i)  <  0 
P  =  i-  a 


Case  12  . 

Southern 

Hemisphere  V 
Retrograde  orbit  f  ^  / 

0  <  (a  -  i)  <  90  p  J ^  ‘ 

P=a-i  ' 


And  finally,  for  Case  12: 

0<(a-i)<90 

fi=a-i  (2.24) 

The  reader  might  notice  a  few  patterns  from 
the  twelve  possible  scenarios  presented  here.  First, 
notice  that  all  cases  can  be  described  by  (a  +  i)  in  the 
northern  hemisphere,  and  (a  -  i)  in  the  southern 
hemisphere.  Second,  despite  the  fact  that  there  are 
twelve  possible  position  scenarios  with  respect  to 
hemisphere,  platform  and  satellite  orbit,  there 
appears  to  be  only  eight  independent  equations  for 
determining  p.  Table  2.1  shows  all  equations  for  P 
listed  together.  Notice  that  some  of  the  cases  have 

the  same  equation  for  determining  p.  From  this 
table  it  becomes  readily  apparent  the  true 
relationship  between  a,  i,  and  p.  This  final 
relationship  is  illustrated  in  Table  2.2.  It  is  these 
equations  in  Table  2.2  that  are  used  to  determine  P 
in  the  preprocessor  software. 


Figure  2.8.  Southern  Hemisphere, 
Retrograde  Orbit  Cases 
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Table  2.1.  A  Summary  of  Twelve  Geometric  Cases  for  Finding  p 


Hemisphere 

Orbit  Type 

(a+i) 

(a-i) 

P 

North 

Prograde 

0<(a+i)<90 

N/A 

P  =  a  +  i 

North 

Prograde 

90<(a+i)<180 

N/A 

P=  180 -a-i 

North 

Prograde 

180<(a+i)<270 

N/A 

O 

00 

1 

+ 

b 

11 

CCL 

North 

Retrograde 

90<(a+i)<180 

N/A 

P  =  180  -  a  -  i 

North 

Retrograde 

180<(a+i)<270 

N/A 

P  =  a  +  i- 180 

North 

Retrograde 

270<(a+i)<360 

N/A 

P  =  360  -a-i 

South 

Prograde 

N/A 

-90<(a-i)<0 

P  =  i  -  a 

South 

Prograde 

N/A 

0<(a-i)<90 

P  =  a-  i 

South 

Prograde 

N/A 

90^(a-i)<180 

p=  180 -hi -a 

South 

Retrograde 

N/A 

-180<(a-i)<-90 

P=  180  + a-i 

South 

Retrograde 

N/A 

-90<(a-i)^0 

P  =  i  -  a 

South 

Retrograde 

N/A 

0<(a-i)^90 

P  =  a-i 

Table  2.2.  The  True  Relationship  Between  p,  a,  and  i 


Hemisphere 

(a+i) 

(a-i) 

P 

North 

0  <  (a+i)  <  90 

N/A 

P  =  a  +  i 

North 

90  ^  (a+i)  ^  180 

N/A 

P=  180-a-i 

180  <  (a+i)<  270 

N/A 

p  =  a  +  i- 180 

270  <  (a+i)  <  360 

N/A 

p  =  360 -a-i 

N/A 

-180  <  (a-i)<  -90 

p=  180  + a-i 

South 

N/A 

-90  <  (a-i)  <  0 

P  =  i  -  a 

South 

N/A 

0  <  (a-i)  <  90 

P  =  a-  i 

South 

N/A 

90  ^  (a-i)^  180 

p  =  180  +  i-a 
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The  final  distillation  of  relationships  between  a,  and  i  shown  in  Table  2.2  no  longer 
uses  the  orbit  type  as  a  reference,  because  the  emphasis  is  more  rigorously  based  upon  the 
combination  of  a+i  and  a-i  on  p. 

2.8.4  Resolution  of  the  Satellite  Critical  Radius 

Knowing  P  and  T  allows  d  to  be  calculated  by  following  another  rule  for 
spherical  triangles; 

sin(c?)  =  sin(j8)  sin('F)  (2.25) 

The  true  anomaly  v  can  be  extracted  in  a  similar  fashion,  assuming  that  the  argument  of 
perigee,  CD,  the  minimal  distance,  d,  the  angle,  P,  and  the  distance,  'F,  in  degrees  are  all 
known: 


sin(v  +  CD)  =  tan(i/)  cot{P) 

(2.26) 

cos(v  +  £u)  =  cos(^)/cos(<i) 

(2.27) 

V  =  (CD+V)-CO 

(2.28) 

Notice  that  finding  both  the  sine  and  cosine  in  Equations  2.26  and  2.27  allow  a  way  to 
resolve  quadrant  errors  which  would  arise  from  using  either  the  sine  or  the  cosine  alone. 
Unfortunately,  v+ft>  can  be  anywhere  from  0  to  360  degrees.  The  sine  or  cosine  alone  can 
only  pinpoint  0  to  180  degrees.  Although  the  method  for  dealing  with  quadrant  errors  is 
straightforward,  the  method  used  for  this  study  is  listed  here  for  clarity  in  Table  2.3. 

From  the  true  anomaly,  the  scalar  radius,  rsat,  of  the  satellite  orbit  at  the  closest  point  may 
be  determined.  The  value  rsat  represents  the  distance  of  the  satellite  from  the  center  of 
the  Earth  at  the  point  where  the  satellite  is  closest  to  the  platform.  Assuming  that  the 
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Table  2.3.  Resolution  of  Quadrant  Ambiguities 


GIVEN  sin(x)  =  y 
cos(x)  =  z 

IF  sin'’(y)  is  positive  or  0  AND  cos'*(z)  is  positive  or  0  THEN 
X  =  sm‘(y) 

IF  sin’’(y)  is  positive  or  0  AND  cos'*(z)  is  negative  THEN 
X  =  180°  -  sin'\y) 

IF  sin'*(y)  is  negative  AND  cos'’(z)  is  positive  or  0  THEN 
X  =  360°  -  sin’’(y) 

IF  sm‘(y)  is  negative  AND  cos'*(z)  is  negative  THEN 
X  =  180°  +  sin'Vy) 


eccentricity,  e,  and  the  semi-major  axis,  a,  are  known, 
equation  for  a  conic  section: 

Tsai  =  a - 

l  +  ecos(v) 


Fsat  can  be  found  by  applying  the 


(2.29) 


Now  that  Fsat  is  known,  it  must  be  compared  to  the  critical  radius,  Fcru,  to  determine 
whether  the  satellite  crosses  the  platform  viewing  horizon.  From  Figure  2.9  it  can  be 
seen  that  the  critical  radius  is  defined  by: 


Fcrif  =  (/?®+/l)/COS(J)  (2.30) 

If  the  satellite  orbit  radius  measured  from  the  center  of  the  Earth  is  greater  than  the 
critical  radius  for  the  orbit,  then  the  satellite  will  have  to  be  further  processed  by  the 
preprocessor  in  order  to  determine  whether  the  ephemeris  reaches  the  platform  horizon 
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R^+h  =  Radius  of  the  Earth  +  the  height  of  the  platform 
d  =  Degree  distance  of  closest  approach  to  the  satellite 


Figure  2.9.  Comparison  of  Satellite  Radius  with  the  Critical  Radius 

plane  during  the  specified  time  interval.  If  the  critical  radius  is  larger,  however,  the 
ephemeris  can  be  discarded  as  out  of  range. 


2.9  Visibility  of  the  Satellite 

To  recap,  the  intention  of  this  preprocessor  analysis  is  to  find  all  satellites  on  the 
input  TLE  file  that  will  be  visible  to  the  platform  from  the  current  time  until  the  time  that 
the  preprocessor  is  next  run.  The  preceding  discussion  has  shown  that  we  can  determine 
whether  the  satellite  is  in  view  of  the  platform,  and  whether  the  satellite’s  ephemeris  is  in 
view.  This  leaves  us  with  four  possible  cases  concerning  the  visibility  of  the  satellite 
from  the  platform.  These  four  cases  are  sununarized  in  Table  2.4.  The  first  case  is  that 
we  have  found  that  the  satellite  is  currently  in  view,  in  which  case  our  analysis  stops  and 
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this  satellite  is  included  in  the  input  TLE  file  to  the  Main  Processor.  The  second  case  is 
that  neither  the  satellite  nor  its  ephemeris  is  visible  before  the  next  run  of  the 
preprocessor,  in  which  case  the  satellite  is  thrown  out  because  it  is  always  out  of  range 
for  the  time  window  of  our  analysis.  The  third  and  fourth  cases  require  a  bit  more 
explanation.  In  the  third  case,  the  satellite  is  not  in  view,  but  its  ephemeris  is  in  view.  As 
stated  previously,  this  presents  a  dilemma  whereby  the  satellite  could  move  into  view  of 
the  platform  before  the  Time  Until  Next  Run  (TUNR)  of  the  preprocessor.  In  this  case, 
the  satellite  could  be  in  view  during  a  window  of  time  after  the  preprocessor  is  run,  but  it 
may  not  be  included  in  the  list  of  satellites  sent  to  the  main  processor  until  the  next  run  of 
the  preprocessor  has  been  made. 


Table  2.4.  Possible  Outcomes  of  Check  to  See  if  Sateliite  is  Visible 


Case 

Satellite 

Satellite  Ephemeris 
Path 

Time  To  Rise 

Visible  To  Platform? 

1 

In  View 

In  View 

N/A 

YES 

2 

Not  In  View 

Not  In  View 

N/A 

NO 

3 

Not  In  View 

In  View 

<TUNR 

YES 

n 

Not  In  View 

In  View 

>TUNR 

NO 

To  catch  this  minor  error,  we  must  make  a  check  to  ensure  that  the  satellite  is  not  going 
to  rise  above  the  artificial  horizon  of  the  platform,  at  least  until  after  the  next  run  of  the 
preprocessor.  If  this  is  the  case,  then  our  satellite  falls  into  case  4,  otherwise,  it  must  fall 
within  case  3. 
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2.10  Checking  Time-to-Rise  of  the  Satellite 

There  are  many  ways  to  check  the  approximate  time  until  the  satellite  rises  above 
the  artificial  horizon.  We  will  benefit  from  realizing  that,  for  our  application,  we  are  only 


RFrT=  Platform  position  vector  in 
ECI  frame 

Feci  =  Satellite  position  vector  in 
ECI  frame 

D  =  Component  of  r^ci  in  Reci 
direction 

Veci= Velocity  vector  of  platform 
Veci  =  Velocity  vector  of  satellite 


Figure  2.10.  Vectors  Used  to  Approximate  Rise  Time 


interested  in  the  case  where  the  satellite  is  very  close  to  the  artijficial  horizon,  because  the 
preprocessor,  as  mentioned  before  should  be  run  every  few  minutes.  Referring  to  Figure 
2.10  above,  we  would  like  to  find  out  how  much  time  passes  before  the  vector  D  has  a 
greater  magnitude  than  the  position  vector  of  the  aircraft,  Reci-  To  do  this,  we  must  find 
the  rate  of  change  of  D  with  time: 

Time  to  Rise  =  ^  ^  (2.3 1) 

D 


Finding  the  derivative  of  D  is  a  tricky  process,  but,  because  we  are  interested  in  only  the 
time  when  the  satellite  is  a  few  minutes  away  from  the  artificial  horizon,  we  can  find  an 
approximation  for  the  derivative  of  D: 


^  ~  ^ECl  '  ^  ^ECI 


Veci 

1^®  +  ^1 


(2.32) 
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In  this  equation,  veci  is  the  satellite  velocity  vector.  R  is  the  unit  vector  in  the  direction 
of  the  platform  position  vector.  Veci  is  the  platform  velocity,  while  r  is  the  satellite 
position  vector;  R®  is  the  radius  of  the  Earth,  and  h  is  the  height  of  the  platform  above 
the  surface  of  the  Earth.  All  of  these  vectors  are  in  the  ECI  frame.  We  can  easily  obtain 
Veq  from  our  time  propagator,  and  both  the  satellite  and  platform  position  vectors  have 
already  been  calculated.  This  leaves  only  the  velocity  of  the  platform  in  the  ECI  frame  to 
calculate.  We  must  assume  that  we  are  given  the  velocity  of  the  aircraft  in  the  ECEF 
frame.  Conversion  to  the  ECI  frame  involves  accounting  for  the  angle,  0g,  that  currently 
separates  the  rotation  of  the  ECEF  frame  with  respect  to  the  ECI  frame,  as  well  as  the 
instantaneous  rate,  ©,  at  which  this  angle  is  increasing.  In  short  the  velocity  of  the 
aircraft  in  the  ECI  frame  will  be; 


V  = 

ECI 


cos6„ 


-sin0„ 


sin0„  cos0„ 


0 


0 


'^ECEF 


0 

0 

2;rrad 


86164.09054  sec 


xR 


ECEF 


(2.33) 


Once  the  rate  of  change  of  D  has  been  determined,  the  approximate  rise  time  from 
equation  2.31  can  be  compared  to  the  Time  Until  Next  Run  (TUNR). 

IfTUNR>TimeToRise  — >  Include  satellite  in  list  given  to  Main  Processor 
If  TUNR  <  Time  To  Rise  Throw  out  satellite  because  it  is  not  visible 

2.11  Preprocessor  Methodology  Conclusion 

The  goal  of  the  ABLPA  Preprocessor  is  to  weed  out  all  satellites  that  are  not 
visible  during  a  given  time  period.  After  running  the  software  that  models  the  algorithm 
described  in  this  chapter,  the  results  indicate  that,  given  a  worst-case  scenario,  at  least 
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75%  of  the  active  satellites  in  the  input  file  are  discarded.  This  leaves  25%  or  less  of  the 
active  satellites  to  be  analyzed  by  the  Main  Processor.  After  the  Preprocessor  has 
finished,  it  sends  the  satellites  that  are  in  view  to  an  output  file,  where  they  can  be  read  by 
the  Main  Processor  when  the  need  arises.  A  more  extensive  analysis  of  the  Preprocessor 
will  be  addressed  in  Chapter  IV. 


\ 
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III.  ABLPA  Main  Processor  Methodology 


We  have  just  finished  discussing  the  ABLPA  Preprocessor,  which  handles  an 
input  file  of  satellite  Two-Line  Element  (TLE)  sets,  and  forms  an  output  file  of  all 
satellites  in  that  list  that  are  in  view  of  the  laser  platform  during  a  given  time.  This 
chapter  will  discuss  the  ABLPA  Main  Processor,  which  is  designed  to  take  this 
“shortened”  list  of  satellites  and  perform  real-time  calculations  to  determine  if  any  of 
these  satellites  will  fall  within  the  predicted  arc  of  the  laser  during  a  given  fire  sequence. 
The  first  step  in  this  calculation  sequence  is  to  determine  the  location  of  each  satellite 
with  respect  to  the  platform. 

3.1  Targeting  the  Satellite 

Up  to  now,  we  have  looked  at  the  positions  of  both  the  platform  and  the  satellite 
as  coordinates  in  the  ECI  frame.  Now,  however  we  wish  to  view  the  satellite  as  it 
appears  with  respect  to  the  platform.  This  is  done  easily  by  switching  to  a  new  platform- 
centered  coordinate  frame. 

3.1.1  The  REN  frame 

This  new  platform-centered  frame  will  be  referred  to  as  the  Radial/East/North 
(REN)  coordinate  frame.  The  three  right-handed  axes  will  consist  of  the  line  from  the 
platform  to  the  north  pole  (the  line  tangent  to  the  path  as  traveled  across  the  spherical 
surface  of  the  Earth),  a  line  traveling  due  East,  and  a  radial  component  “up”  from  the 
center  of  the  Earth.  In  this  coordinate  frame,  the  platform  position  will  be  made  the 
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center  by  subtracting  its  position  from  other  bodies  also  referenced  in  the  REN  frame.  A 
representation  of  this  new  coordinate  frame  is  shown  in  Figure  3.1.  Using  this  frame  of 
reference,  a  new  position  vector,  p,  will  refer  to  the  position  of  the  satellite  with  respect 

Rjci  =  Platform  position  vector  in  ECI  frame 
r^ci  =  Satellite  position  vector  in  ECI  frame 
P  =  r^rr-  Rprr  or  the  satellite 
in  Ihe  REN  frame. 


Figure  3.1.  Derivation  of  p  in  ECi  Frame  With  Respect  to  the  REN  Frame 

to  the  platform.  The  vector  p  can  be  derived  from  the  two  vectors  Reci»  the  platform 
position  in  the  ECI  frame  as  referenced  from  the  center  of  the  Earth,  and  fecij  the  satellite 
position  vector  in  the  same  frame: 

P ECI  ~^ECI  ~^EC/  (3-1) 

where: 

PeCI  ~  Px^  Pyj  Pz^  (3-2) 

we  want  to  obtain  p  in  the  REN  frame: 

PrEN  ~  Pr^"^  Pe^"^  Pn^  (3-3) 
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To  find  this  vector  in  the  REN  frame,  we  must  first  find  the  conversion  matrix  that  will 
take  us  from  the  ECI  coordinate  frame  to  the  REN  frame.  This  coordinate  transformation 
matrix  is  simply: 


/s 

R  i  R  j  R  k 

PREN  “ 

A.  ^  Ak  A  A 

E  i  E  j  Ek 

Py 

N-i  N-j  N-k 

J 

While  the  i,  j,  and  k  unit  axis’  of  the  ECI  frame  have  been  defined  already,  the  R,  E,  and 
N  unit  axis’  of  the  REN  frame  have  not  yet  been  rigorously  defined.  The  R  unit  axis 
direction  can  be  seen  to  be  the  same  direction  as  the  position  vector  of  the  aircraft  in  the 
ECI  frame  (pointing  up  from  the  center  of  the  Earth): 


R 


Ecn 


(3.5) 


The  E  unit  direction  can  be  derived  from  the  angular  motion  of  the  Earth  crossed  with  the 
aircraft  position  vector  direction: 

E  =  (3.6) 

(O^  X  R 


Similarly,  because  the  REN  coordinate  frame  is  right-handed: 

N  =  RxE  (3.7) 

Armed  with  this  information,  p  can  now  be  found  in  the  REN  frame. 
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3.1.2  Determining  Laser  Position  in  the  REN  Frame 

Now  that  we  have  the  position  vector  of  the  satellite  with  respect  to  the  aircraft,  it 
is  a  fairly  easy  matter  to  find  the  unit  position  vector  of  the  laser.  Assume  that  the  laser 
Azimuth  (Az)  and  Elevation  (El)  will  be  known.  Az  will  be  given  in  degrees  east  of 
north.  El  will  be  given  in  degrees  above  the  platform  artificial  horizon. 


Figure  3.2.  Laser  Position  in  the  REN  Frame 


Looking  at  Figure  3.2,  it  is  fairly  straightforward  to  derive  the  unit  position  vector  L  in 
the  REN  frame.  L  describes  the  unit  direction  in  which  the  laser  is  pointing  in  the  REN 
frame,  and  has  unit  magnitude: 


sin(£'/) 

R 

L  = 

cos(El)  sin(Az) 

E 

cos(El)  cos(Az) 

N 

With  these  two  vectors,  p  and  L,  we  now  have  a  way  to  compare  the  position  of  the 
satellite  with  the  position  of  the  laser  turret,  both  of  which  are  given  in  the  REN  frame. 
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3.2  Position  Error 


Up  until  this  point,  we  have  been  addressing  the  position  of  the  satellite  and  laser 
arc  as  points  that  are  both  fixed  and  known.  However,  applying  this  to  an  operational 
setting  will  quickly  reveal  that  the  exact  position  of  both  the  laser  and  the  satellite  are 
only  known  within  some  degree  of  error.  These  errors  introduce  a  growing  uncertainty 
that  must  be  modeled  and  accounted  for  if  we  are  to  reliably  deconflict  the  path  of  the 
laser  with  the  ephemeris  of  the  satellite.  There  are  a  number  of  uncertainties  that  the 
reader  may  have  noticed  thus  far.  The  first  set  of  uncertainties  involve  the  positions  of 
the  platform  (or  laser  turret),  satellite,  and  the  missile.  Our  current  level  of  technology 
allows  us  to  establish  and  forecast  positions  in  the  ECI  frame  fairly  accurately,  but  each 
position  estimate  or  forecasted  position  estimate  will  still  have  an  uncertainty.  The 
second  set  of  uncertainties  concern  the  laser  itself.  Each  of  these  errors  will  be  addressed 
here. 

3.2.1  Platform  Position  Error 

The  laser  platform,  in  the  case  of  the  ABL  program,  is  a  Boeing  747-400  airframe 
equipped  with  a  Hone5rwell  GPS  package.  According  to  Honeywell,  this  GPS  system 
will  be  accurate  to  within  10  meters.  This  being  the  case,  we  will  have  an  instantaneous 
position  error  of  only  ±  10  m  or  .01  km.  This  error  is  fairly  small.  However,  given  the 
nature  of  the  Predictive  Avoidance  mission,  we  have  the  need  to  forecast  the  plane’s 
position  into  the  future  by  approximately  20-30  seconds,  in  order  to  fully  encompass  the 
necessary  laze  time  to  destroy  the  missile.  Recall  that  the  firing  solution  must  be  derived 
in  the  second  before  the  laser  fires,  so  that  the  laser  can  fire  for  an  uninterrupted  amount 
of  time.  This  amount  of  time  is  not  expected  to  exceed  30  seconds.  Therefore,  we  must 
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also  know  the  path  of  the  airplane  in  those  20-30  seconds.  It  is  assumed  by  the  author 
that  the  trajectory  of  the  platform  will  be  somehow  actively  controlled  by  an  autopilot,  so 
that  any  deviations  from  the  planned  course  will  be  corrected  in  real-time.  Given  this 
type  of  active  control  system,  the  author  assumes  that  the  position  error  of  the  plane, 
working  in  conjunction  with  the  Honeywell  GPS,  should  not  exceed  ±  50  meters  or  0.05 
kilometers. 


Figure  3.3.  Computing  the  Error  Angle  Contributed  By  Platform  Position 

Error 


Consider  the  illustration  given  in  Figure  3.3.  The  inputs  that  are  currently  known  are  the 
absolute  range  to  the  satellite,  the  range  to  the  missile,  Rm,  the  position  error  of  the 
platform,  Rp,  and  the  approximate  intermediate  distance  between  the  missile  and  the 
satellite,  Ri.  Notice  that  Ri  can  be  approximated,  by  subtracting  Rm  from  the  absolute 
range  to  the  satellite  when  the  satellite  is  close  to  intersection  with  the  laser.  The  goal  is 
to  find  the  effective  error  angle,  Ep,  contributed  by  the  unknown  location  of  the  platform. 
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From  the  initial  known  parameters,  the  downrange  spread  distance,  Sa,  can  be 


approximated  by: 


S 


d 


(3.9) 


Knowing  Sa  allows  the  computation  of  the  effective  error  angle  Ep: 

'‘m  '■/ 

It  can  be  seen  here  that  Ep  will  have  a  bigger  impact  on  the  overall  error  angle  as  the 
range  to  the  satellite  increases.  As  the  satellite  moves  farther  away  from  the  platform,  the 
error  angle  due  to  satellite  position  uncertainty  will  decrease,  while  Ep  will  remain 
constant.  Thus,  Ep  will  play  an  ever  more  prominent  role  as  the  range  to  the  satellite 
increases. 


3.2.2  Satellite  Position  Error 

The  satellite  position  error  is  the  dominant  position  error  in  the  error  budget  for 
almost  all  cases.  The  position  of  the  satellite,  as  mentioned  before,  is  a  forecast  derived 
from  SGP4.  In  the  period  of  20-30  seconds,  the  error  ellipsoid  in  which  the  satellite  can 
be  expected  to  reside  will  not  change  significantly.  However,  from  the  outset,  the  error 
ellipsoid  will  be  big.  Without  conducting  a  thorough  study  of  SGP4,  there  is  no  concrete 
way  to  establish  an  exact  error,  or  rate  of  change  of  error.  Furthermore,  at  this  time  we 
do  not  know  how  current  the  satellite  input  to  SGP4  will  be.  If  SGP4  is  expected  to 
propagate  over  a  period  of  hours,  the  error  will  be  significantly  less  than  if  propagation  is 
conducted  over  a  period  of  days  or  weeks.  In  the  absence  of  accurate  data,  and  realizing 
that  the  propagation  is  likely  to  be  less  than  a  day,  it  will  be  assumed  that  the  position  of 
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the  satellite  is  established  at  ±  10000  meters  or  10  km.  Given  30  years  of  satellite 
tracking  history  with  SGP4,  this  position  error  estimate  appears  to  be  a  reasonable 
average.  The  satellite  position  error  will  also  be  a  parameter  in  the  software  that  can  be 
changed  as  the  customer,  if  deemed  necessary.  Assuming  that  the  position  error  radius  of 
the  satellite,  R*,  can  be  approximated,  the  error  angle  contributed  by  the  satellite  will  be: 

E,  =tan-'&)  (3.11) 

|P| 

Where  Ipl  represents  the  range  to  the  satellite.  Notice  that  this  error  angle  will  decrease 
as  the  range  to  the  satellite  increases. 


3.2.3  Missile  Position  Error 

Up  to  this  point,  the  missile’s  position  has  been  thought  of  only  as  an  extension 
from  the  laser  turret.  At  the  time  of  laze,  the  turret  line  of  sight  must  be  positioned  on  the 
missile  such  that  there  is  no  more  than  ±1-2  meters  of  error.  If  this  is  not  so  then  the 
laser  will  never  reach  its  target,  and  the  ABL  program  in  general  is  in  serious  jeopardy. 
The  range  to  the  missile  is  also  assumed  to  be  known  within  1-2  meters.  What  we  do  not 
know  is  the  behavior  of  the  missile  when  forecasted  over  time.  It  has  been  assumed  that 
the  turret  slew  rates  currently  used  to  keep  the  missile  locked  will  not  change  over  our 
30-second  forecast  span.  Hence,  with  regard  to  the  turret  slew  rate,  S,  we  must  assume 
that: 


c  =  c 

forecast  lock 

s  =  s 

^  forecast  ^  lock 


and 


(3.12) 


It  is  not  necessarily  reasonable  to  expect  that  this  will  be  true.  The  ABL  platform  is 
intended  to  intercept  a  missile  during  its  initial  boost  stage,  where  it  is  the  most 
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predictable  and  vulnerable.  If  this  is  the  case,  then  the  position  error  of  the  missile  is 
orders  of  magnitude  less  than  the  position  error  of  the  satellite,  with  a  position  error 
sphere  of  roughly  ±  50  meters. 


Figure  3.4.  Illustration  of  the  Error  Angle  Introduced  by  Uncertain 

Missile  Position 


Referring  to  Figure  3.4,  if  the  radius  of  this  missile  position  error  sphere,  Mp,  and  the 
range  to  the  missile,  Rm,  are  known,  then  the  error  angle  introduced  by  the  missile 
position  uncertainty,  E^,  will  be: 

£:„=tan-’(^)  (3.13) 

m 

Notice  that  the  error  angle  will  increase  as  the  platform  gets  closer  to  the  missile.  Also 
notice  that,  if  the  missile  behaves  in  such  a  way  that  significant  discrepancies  are 
introduced  into  its  trajectory,  then  the  position  error  can  easily  increase  from  50  meters  to 
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5  kilometers.  There  are  two  ways  to  account  for  this  error  in  a  forecast.  The  first  method 
is  to  introduce  a  significantly  larger  missile  position  error  into  the  forecast,  which  will 
inevitably  cause  a  much  bigger  error  angle  in  our  forecast.  This  is  not  very  desirable,  as 
it  increases  our  error  angle  as  much  as  two  full  degrees,  and  gives  the  user  a  smaller 
space  with  which  to  work.  The  second  method  is  to  recompute  in  mid-laze,  should  the 
lazing  parameters  stray  considerably  from  initial  conditions.  While  this  may  seem  at  first 
to  also  be  undesirable,  it  can  seen  that  this  method  tightens  the  error  angle  considerably, 
allowing  a  substantially  reduced  chance  that  a  forecast  will  result  in  a  satellite  hit.  K  no 
satellites  were  previously  forecast  to  be  intersected,  then  rerunning  the  Main  Processor  in 
mid-laze  presents  only  an  extremely  small  chance  of  forecasting  an  intersection  of  a 
satellite.  The  alternative  to  recomputation  is  to  incorporate  a  position  compensation  error 
of  two  or  more  kilometers  into  the  position  error  of  the  missile,  adding  whole  degrees  to 
our  error  angle. 

3.3  Laser  Diffraction  Errors 

Normally  one  would  think  of  a  laser  beam  as  being  fairly  concentrated,  without 
much  diffraction  error.  This  is  essentially  the  case  between  the  platform  and  the  missile, 
where  the  range  is  only  200  km  or  so,  and  the  beam  is  “focused”  on  the  target.  However, 
when  dealing  with  the  range  to  an  orbiting  satellite,  with  distances  of  six  Earth  radii 
(GEO  altitude),  beam  diffraction  has  the  potential  to  become  a  significant  factor.  There 
are  two  areas  that  we  must  consider  when  attempting  to  determine  how  a  beam  will 
spread  out  over  long  distances.  The  first  area  deals  with  intrinsic  errors  within  the  laser 
itself,  and  the  second  area  covers  optical  diffraction  and  divergence. 
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3.3.1  Laser  Intrinsic  Spread  Error 


In  theory,  a  laser  should  have  no  intrinsic  spreading  error,  as  every  photon  is  at 
the  same  wavelength  and  has  the  same  propagation  direction.  In  practice,  however,  every 
laser  has  imperfections  in  its  optics  and  propagation  that  cause  the  beam  to  diverge. 
These  divergent  patterns  may  be  caused  by  very  small  imperfections  in  the  alignment  of 
the  optics,  transmission  medium,  or  by  a  host  of  other  factors.  Unfortunately  the  intrinsic 
spread  error  of  the  ABL  lasers  have  not  been  made  available  to  us,  and  so  the  role  it  plays 
cannot  be  accurately  discussed.  However,  we  must  assume  that  a  laser  designed  to  hit  a  2 
meter  square  target  at  200  km  is  also  designed  to  have  a  very  small  intrinsic  error. 
Therefore  we  will  assume  this  spread  to  be  small  enough  to  ignore,  when  compared  with 
the  significantly  larger  error  angles  introduced  by  position  errors.  It  is  mentioned  here 
only  for  the  purposes  of  pointing  out  that  it  has  a  potential  for  becoming  a  significant 
error  source. 

3.3.2  Optical  Diffraction  and  Beam  Divergence 

The  ABL  High  Energy  Laser  (HEL)  is  a  “strongly  focused”  laser.  That  is,  the 
optics  are  designed  so  that  the  beam  will  narrow  from  the  aperture  diameter  of 
approximately  1.5  meters  to  the  theoretical  “diffraction-limited  spot-size”,  which  is  the 
smallest  possible  spot  to  which  the  laser  can  focus  to.  An  illustration  of  this  is  shown  in 
Figure  3.5.  From  this  simple  illustration  it  can  be  seen  that  the  laser  beam  diverges  in  a 
parabolic  path,  but  slowly  conforms  to  a  diffraction  angle,  Odiff-  The  angle,  9diff  can  be 
modeled  by  the  equation: 

(3.14) 

TtW^ 

Where  X  is  the  wavelength  of  the  laser  (in  this  case  assumed  to  be  1 .3 15  pm  for  the  HEL, 
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Light  Amplifier  Propagated  Beam 


/ 


Wj  =  Radius  of  narrowest  point  (waist)  of  the  light  amplifier 
Wj  =  Radius  of  narrowest  point  (waist)  of  the  focused  beam 
6piFF= Diffraction  angle  approximating  the  divergence  of  the  beam 
f  =  focal  length  (distance  to  the  focus  point) 

Figure  3.5.  Exaggerated  Divergence  of  a  Highly  Focused  Beam 


1.03  |im  for  the  TILL,  or  1.06  )im  for  the  BILL),  and  W2  is  the  radius  of  the  narrowest 
part  of  the  focused  beam.  W2,  in  turn  can  be  found  if  wj  is  known: 


w 


2 


(3.15) 


Where  wj  represents  the  radius  of  the  narrowest  point,  or  “waist”  of  the  radiation 
amplification  chamber  of  the  laser,  and  f  is  the  focal  length.  Unfortunately,  we  are  not 
privy  to  the  specifications  of  the  laser  mechanism,  so  we  need  to  find  another  way  to 
estimate  W2.  We  can,  for  instance,  assume  that  the  designers  of  the  ABL  HEL  system 
will  wish  to  focus  the  laser  as  close  to  the  theoretical  limit  as  possible,  approaching  the 
diffraction-limited  spot  size: 


Spot  Size  =  /  tan( — ) 


(3.16) 


Setting  W2  equal  to  the  diffraction  limited  spot  size  should  present  a  fairly  close  estimate 
to  the  actual  value  of  wj,  and  would  yield  the  equation: 

^  (3.17) 

^tan(— ) 

In  this  way,  we  can  approximate  the  beam  dispersion  by  knowing  only  the  focal  length 
and  aperture  size  of  the  laser. 

3.4  Other  Error  Considerations 

There  are  other  errors  that  can  pop  up  in  our  estimation  of  the  probability  to  laze  a 
satellite.  The  most  notable  error  is  the  uncertainty  that  the  satellite  is  traveling  with 
constant  speed  and  direction.  Our  time  propagator  assumes  there  are  no  forces  acting  on 
the  satellite  other  than  the  pre-existing  conditions  and  two-body  gravitational  effects. 
However,  if  the  satellite  undergoes  station-keeping  maneuvers,  or  is  otherwise  deflected 
from  its  course  by  some  unforeseen  event,  the  error  can  quickly  become  catastrophically 
worse  over  a  surprisingly  short  period  of  time.  Now  the  question  must  be  asked  as  to 
whether  or  not  we  should  choose  to  try  to  model  these  events  and  somehow  account  for 
them.  This  author  would  argue  that  the  answer  is  no.  To  attempt  to  trap  all  possible 
errors,  even  those  occurring  beyond  the  3a  realm  of  possibility,  would  constrain  the 
problem  to  such  a  degree  as  to  make  it  unwieldy  without  adding  much  fidelity.  We  must 
assume  that  the  satellite  TLE  files  are  only  hours  (at  most)  old.  In  this  time,  it  is 
conceivable  that  a  few  station-keeping  maneuvers  have  occurred  on  a  few  satellites. 
However,  the  chances  that  a  given  satellite  has  been  maneuvered  within  a  few  hours  and 
happens  to  cross  the  laser  beam  at  the  time  it  is  fired  are  so  infinitesimal  as  to  preclude 
them  from  consideration.  Such  a  chance  certainly  does  not  justify  adding  an  additional 
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two  degrees  or  so  to  every  LEO  satellite  position  error  angle!  Therefore,  the  possibility 
of  station-keeping  maneuvers  is  best  left  out  of  the  project.  Some  of  this  error  could, 
however  be  accounted  for  by  increasing  the  position  error  of  the  satellite,  if  desired. 

A  second  problem  with  the  error  analysis  seen  in  the  previous  pages  is  that  all 
position  errors  are  modeled  as  a  sphere.  For  the  platform  position  error,  this 
approximation  may  be  accurate.  However,  for  the  forecasted  missile  and  satellite 
positions,  it  is  unlikely  that  this  is  the  case.  The  missile’s  position,  for  example,  is 
initially  known  to  within  a  meter  of  our  reference  point,  the  platform.  As  time  progresses 
within  the  forecast,  the  missile’s  position  error  will  likely  radiate  from  its  known  starting 
point  as  a  elongated  ellipsoid,  rather  than  a  sphere,  as  the  acceleration  is  the  most 
uncertain  parameter,  not  necessarily  direction.  Furthermore,  the  satellite’s  position  error 
is  probably  more  accurately  modeled  as  a  highly  eccentric  ellipse,  because  its  altitude  is 
likely  to  be  more  established  than  its  orbital  progress.  In  future  iterations  of  this  project, 
it  may  be  beneficial  to  model  these  position  errors  using  a  covariance  matrix,  rather  than 
an  absolute  error  angle. 

3.5  Error  Budget  Consolidation 

Now  that  we  have  assessed  the  errors  that  exist  within  our  error  budget,  we  can 
begin  to  consolidate  these  errors  into  one  error  angle.  You  will  notice  that,  of  all  the 
errors.  Satellite  Position  Error  seems  to  be  the  biggest  in  most  cases.  This  is 
demonstrated  in  Table  3.1,  which  shows  the  magnitude  of  both  the  error  angle  as  seen 
from  the  platform,  and  the  position/displacement  error  as  seen  downrange  at  the 
satellite’s  distance  from  the  platform,  at  both  a  LEO  and  GEO  range.  Knowing  each  of 
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the  error  angles  computed  above  allows  computation  of  the  overall  error  angle  as  seen  by 
the  platform. 


Table  3.1.  Error  Budget  for  Predictive  Avoidance  Using  the  High  Energy 
Laser  (HEL)  with  a  Waveiength  of  1 .31 5  pm 


Error 

Vj  Angle  Error 
At  LEO  Alt 
Range  =  500  km 

Vi  Angle  Error 

At  GEO  Alt 
Range  =  36,000  km 

Displacement 
Error  At  LEO 
Range=500  km 

Displacement 
Error  At  GEO 
Range  =  36,000  km 

Airplane 
Position  Error 
=  ±50m 

0.01424  deg 

0.01424  deg 

±124  m 

±  8950  m 

Missile 

Position  Error 
=  ±50m 

0.01432  deg 

0.01432  deg 

±125m 

±  9000  m 

Satellite 
Position  Error 
=  ± 10000  m 

1.14576  deg 

0.01592  deg 

±  10,000  m 

±  10,000  m 

Laser 

Divergence 

0.00014  deg 

0.00014  deg 

±  1  m 

±88m 

Laser 

Intrinsic  Spread 

Unknown, 
Assumed  Small 

Unknown, 
Assumed  Small 

Unknown, 
Assumed  Small 

Unknown, 
Assumed  Small 

1.14588  deg 

0.023072  deg 

±  10,002  m 

±  16,159  m 

The  values  in  Table  3.1  were  computed  using  a  focal  length,/,  of  200  km  (the  range  to 
the  missile)  and  the  HEL  wavelength.  Estimates  for  the  BILL  and  TILL  lasers  will  be 
very  simili",  as  their  wavelengths  are  fairly  close  to  the  HEL  wavelength,  and  Laser 
Divergence  is  a  minimal  contribution  to  the  overall  error  angle.  Each  of  the  error  sources 
is  independent  of  the  others,  so  the  Total  Error  is  simply  found  by  taking  the  square  root 
of  the  sum  of  the  squares  of  the  individual  errors.  Thus,  the  overall  error  angle,  a,  can  be 
computed  by  knowing  the  error  angle  contributed  by  the  position  errors  of  the  satellite. 
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missile,  and  platform  (Eg,  Em,  and  Ep  respectively)  as  well  as  the  Laser  Divergence  angle, 
Bdiff'- 

a  =  ^E;^  +  Ej  +  E;+e^J  (3.18) 

Notice  that  the  error  angle  is  largely  dependent  upon  the  range  to  the  satellite  in  question. 
LEO  orbiting  satellites  introduce  a  much  larger  error  angle  than  the  GEO  satellites, 
because  of  their  proximity  to  the  platform.  Also  notice  that  the  error  angle  is  largely 
dominated  by  the  position  errors,  which  in  every  case  establish  at  least  99.99%  of  the 
Total  Error.  This  brings  up  an  interesting  short  cut.  As  mentioned  previously,  the  Main 
Processor  is  extremely  constrained  by  processing  time,  because  it  must  run  in  real  time. 
Therefore  we  must  ask  whether  or  not  the  additional  0.01%  error  contributed  by  Laser 
Divergence  is  worth  the  extra  processing  necessary  to  calculate  it.  Almost  certainly,  it  is 
not.  Therefore  the  processor  should  be  able  to  ignore  this  error  and  save  a  small  amount 
of  processing  time  without  sacrificing  much  fidelity: 

a  =  +  £,"+£/  (3.19) 

In  the  future,  as  position  tracking  for  the  ABL  system  becomes  more  refined.  Laser 
Divergence  error  may  play  a  bigger  role,  and  thus  have  to  be  included  in  the  error  angle 
calculation.  Until  that  time,  the  radius  of  our  “position  error  cone”  can  be  described  as  an 
angle,  a,  which  described  in  equation  3.19. 
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3.6  Finding  the  Current  Separation  Angle 


To  recap,  first  the  satellite  position  vector,  p,  was  computed  in  the  REN  frame, 
followed  by  the  unit  position  vector  of  the  laser,  L,  also  in  the  REN  frame.  In  the  last 
section,  the  error  angle,  a,  was  derived.  Now,  referring  to  Figure  3.6,  everything  is  in 
place  to  find  the  angle,  fi,  that  separates  the  laser  from  satellite. 


a  =  Error  Angle 
p  =  Separation  Angle 
p  =  Sat  position  Vector 
L  =  Laser  position  vector 


Figure  3.6.  Illustration  of  the  Separation  Angle 


Finding  this  angle  is  a  fairly  trivial  matter: 


P 


=  cos 


(3.20) 


However,  forecasting  the  change  of  this  angle  with  time  is  somewhat  more  involved. 


3.7  Forecasting  the  Separation  Angle 

Previously,  it  was  stated  that  the  requirement  exists  to  forecast  the  separation  of 
the  laser  with  a  given  satellite  up  to  30  seconds  into  the  future.  In  order  to  attempt  such  a 
task,  it  is  first  necessary  to  know  the  rate  of  change  of  as  well  as  its  acceleration. 
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3.7.1  Finding  the  Rate  of  Change  of  the  Separation  Angle 

The  rate  of  change  of  j8  is  simply  its  derivative.  Recall  from  equation  3.20  that: 


„  pL 

p  =  cos  (m)  where  u  =  .  _. 


Therefore,  taking  the  derivative: 
-1  du 


(3.21) 


^  dt 

where : 


(3.22) 


u  = 


pL 


and 


du 

dt 


f  -  -  -  -  - 

pL  ^pL  pL  pp 


|P|  Ipf  |P| 

From  equation  3.22,  the  rate  of  change  of  P  can  now  be  computed,  provided  we  can  find 
the  rate  of  change  of  the  unit  laser  direction  vector  L,  and  the  rate  of  change  of  the 
satellite  position  vector,  p.  Recall  from  equation  3.8  that  the  initial  laser  position  is  given 
by  its  azimuth  and  elevation: 


sinfE’Z) 

r' 

L  = 

cos(El)  sin(Az) 

E 

cos(El)  cos(  Az) 

N 

Assume  also  that  the  rate  of  change  and  accelerations  of  the  Azimuth  and  Elevation, 
Az ,  Az,  El,  and  El  are  also  given.  This  is  to  be  expected,  as  they  will  undoubtedly  be 
made  available  from  the  electrical  current  controlling  the  laser  tracking  mechanism.  This 
being  the  case,  the  rate  of  change  of  L  is  easily  found  by  taking  the  derivative: 


cos(El)Ei 

R 

L  = 

cos(El)  cos(Az)Az  —  sin{El)  sin(Az)E/ 

A. 

E 

— cos(E/)  cos( Az) Az  -  sin(E/)  cos( Az)£'/ 

N 

(3.22) 


51 


Now  all  that  remains  is  to  find  the  rate  of  ehange  of  p.  Recall  from  equations  3.1  through 
3.4  that: 


Peci 

^ECl 

■"a  a 

R  i 

A  A 

R  j 

A  A 

R  k 

Pren  ” 

/V  ^ 

Ei 

e] 

A  A 

E  k 

A  ^ 

N-i 

N-j 

N-k 

Py 

\^Pz  ) 

T 


Where  i,  j,  and  k  are  the  X,  Y  and  Z  unit  axis’  of  the  ECI  frame,  teci  is  the  position  of 
the  satellite,  Reci  is  the  position  of  the  aircraft,  and  R,  E,  and  N  are  the  unit  directions  of 
the  REN  frame.  It  stands  to  reason  that  the  rate  of  change  of  p  can  be  found  in  a  similar 

manner: 

^  d  -  _  ^  ^  R  (3.23) 

The  reader  may  recall  from  Chapter  2  that  the  velocity  of  the  platform  has  already  been 
derived  in  the  ECI  coordinate  frame  in  equation  2.33: 


d  « 


dt 


ECI 


cos6g  -sin^g  0 
sin^„  cos^„  0 


0 


0 


ECEF 


0 

0 

2;r  rad 


,86164.09054  sec 


xR 


ECEF 


Furthermore,  the  velocity  of  the  satellite  in  the  ECI  frame  can  be  extracted  directly  from 
SGP4.  Therefore  all  of  the  components  necessary  to  find  the  rate  of  change  ofp  in  the 
ECI  frame  are  available.  All  that  remains  is  to  find  this  rate  of  change  with  respect  to  the 
REN  frame.  This  is  done  as  is  was  previously,  multiplying  by  the  same  conversion 
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matrix  used  to  transfer  the  satellite  position  vector  from  the  ECI  frame  into  the  REN 
frame: 

R  i  R  j  R  k  ("p/ 

E-i  E-j  E-k  •  p^  (3.24) 

N-i  N-j  N-kJ  [p,  ^ 

Armed  with  the  rate  of  change  of  p  and  L,  the  rate  of  change  of  the  separation  angle 
quickly  follows  from  equation  3.22. 

3.7.2  Finding  the  Acceleration  of  the  Separation  Angle 


The  only  obstacle  that  remains  in  the  quest  to  find  an  approximate  forecast  of  the 
separation  angle,  is  to  find  the  rate  of  change  of  the  rate  of  change,  or  the  acceleration  of 
the  separation  angle  p.  Recall  from  equation  3.22  that: 

-  .L  -  -  J.  ^ 

pL  ^  pL  pL  pp 

P\  \p\ 


Finding  the  acceleration,  or  the  second  derivative,  of  P  requires  taking  the  method  used  in 
the  previous  section  one  step  further,  and  finding  the  derivative  of  p.  It  may  be  easier  to 


visualize  the  derivation  of  the  acceleration  by  breaking  the  rate  of  change  into  two 
smaller  functions: 
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From  this  it  can  be  seen  that: 


P  =  udv  +  vdu 
where : 


-1 


u  = 


and 


V  = 


^  —  .1'^ 

p  '  L  p  ’  L  P  '  L  p  '  p 


'-h‘ 


\p\  IpI 


^|2 


.-3/ 


du  = 


r-  ;VV/2  r 

pL 


P 


pL^pL  pL  pp 


|P|  \pf  |P 


'^P-l'' 

IpI 


and 


dv  = 


pL  ^  pL  pL  pp 

\p\  \P\  \pf  \P 


+ 


pL  pL  pL 

|p|  p  P' 

P  1 

PP 

^2{pl){p-p) 

{  ■  ^  -AY 

pL+  pL 

[h  J 

[  ipr 

JJJ 

pL 


LV 


PP  pp  pp 

[  ipi  ipi  ■  ipr 


pp 


VJ 


(3.26) 


This  somewhat  longer  equation  for  the  acceleration  of  brings  with  it  two  more 
terms  that  require  further  derivation.  Just  as  finding  P  required  finding  Land^,  so  also 


the  derivation  of  j3  introduces  the  variables  L  and  p.  Again,  the  derivation  of  the 
acceleration  of  L  follows  from  the  derivation  of  the  rate  of  change  of  L.  Recall  that: 


cos(El)Ei 

R 

L  = 

cos(El)  cos(Az)  Az  -  sin(£/)  sm(Az)El 

/s 

E 

— cos(El)  cos(  Az)Az  -  sin(El)  cos(Az)El 

N 
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Therefore  it  follows  that  the  acceleration  of  L  will  simply  be  the  derivative  with  respect 
to  time  of  the  rate  of  change: 


cos{El)El  -sm{El)Ei  •  Ei 


cos{El)cos(Az)Az  -  Azipos{El)  sin(i4z)Az  +  sin(£'/)cos(Az)£'/)- 
sin(£'/)  sm(Az)Ei  -  Eii^in(El)  cos(Az)Ai  +  cos(El)  sin(Az)£'/) 


cos(£/)sin(Az)Az  +  Az(cos(£'/)cos(Az)Az  -  sin(£'/)sin(Az)£'/)- 
sin(£'Ocos(Az)E/  -  Eiipos(El)cos(Az)Ei  -  sin(£'/)sin(Az)Az) 


R 

A 

E 

N 


(3.27) 


As  stated  previously,  we  have  assumed  that  the  acceleration  of  both  the  Az  and  the  El  are 
given.  The  only  value  left  to  derive  is  p .  Realizing  that  this  can  be  found  in  the  ECI 
frame  and  then  converted  to  the  REN  frame  in  a  similar  manner  as  the  rate  of  change 
derivation  allows  computation  of  the  acceleration  in  the  ECI  frame; 


-  _  - 

PeCI  ~  PeCI  ~ 


_ 

dt^ 


(3.28) 


Finding  the  acceleration,  r ,  of  the  satellite  at  any  given  position  is  fairly  straightforward 
in  the  ECI  frame: 


-Pe  -r 

3 

r 


(3.29) 


The  gravitational  constant  for  the  Earth,  jU®,  is  roughly  398601  km^/sec^.  Recall  that  the 
platform  velocity  in  the  ECI  frame  is: 


COS0^ 

sin6>^ 

0 


-sin0^ 

COS0^ 

0 


'  ^  ECEF  ^  ^ 


ECEF 


(3.30) 
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Where  co  represents  the  angular  rotation  of  the  Earth  as  shown  in  equation  2.23.  Because 
the  platform  is  flying  a  fixed  course,  intentional  acceleration  due  to  course  change  should 
zero,  or  very  close  to  zero.  Thus  we  are  left  with  only  the  Coriolis  and  Centripetal 
accelerations  in  the  acceleration  derivative: 

~  2(0 X 


cos6„ 

-sin0„ 

0‘ 

8 

d  - 

sin0^ 

COS0J 

0 

p 

dt 

0 

0 

1 

+  X  X  R )  (3.31) 


Both  the  first  term  in  equation  3.31,  the  Coriolis  acceleration,  and  the  second  term,  the 
Centripital  acceleration,  should  be  fairly  small  compared  with  the  acceleration  of  the 
satellite,  because  the  platform  will  not  be  “moving”  nearly  as  fast  as  the  satellite  with 
respect  to  the  ECI  frame.  Nonetheless,  it  has  been  decided  to  include  the  platform 
acceleration  in  the  calculation  of  p ,  even  if  only  for  theoretical  completeness,  as  its 
inclusion  does  not  significantly  degrade  software  performance.  After  finding  the 
acceleration  of  p  in  the  ECI  frame,  it  can  also  be  translated  to  the  REN  frame  using  the 
/  matrix  employed  in  previous  translations: 


R  i  R  j  R  k 

'p.Y 

ZV  A.  zv  zv  zv  zv 

PREN  “ 

E  i  E  j  E  k 

^  A  ^  ^  Ak  Ak 

• 

Py 

N-i  N-j  N-k 

(3.32) 


We  now  have  all  of  the  components  necessary  to  build  an  initial  forecast  using  the 
equations  for  jS,  $,and  $,  for  the  separation  angle  between  the  laser  and  the  satellite  at 
some  given  time  in  the  future. 
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3.7.3  The  Forecast  Method 


Now  that  j3,  and  have  been  found  from  initial  conditions,  there  are  a 
number  of  ways  to  approximate  fiat  a  future  time.  The  goal  is  to  find  the  time  (or  times) 
that  the  laser  will  pass  closer  than  the  error  angle  to  the  exact  predicted  position  of  the 
satellite.  Referring  to  Figure  3.6,  the  goal  is  to  find  any  time  in  which  the  error  angle,  a, 
is  greater  than  or  equal  to  the  predicted  value  of  p.  Recognizing  this,  it  can  be  seen  that 
the  forecast  for  P  fits  into  a  second-order  Taylor  series  expansion: 


p{t)=a  =  P„  + pAt  +  ^pAt^  (3.33) 

and  solving  for  t  will  gives  us  the  times,  if  any,  when  intersects  this  region.  This  is 
illustrated  in  Figure  3.7.  In  actuality,  the  motion  of  the  satellite  with  respect  to  the  plane 
might  better  be  described  by  a  sine  wave  that  varies  in  amplitude  and  frequency 


iS 


Figure  3.7.  Illustration  of  a  Satellite  “Intersection”. 
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somewhere  between  zero  and  K  radians  as  the  days  and  weeks  go  by.  However,  for  the 
short  amount  of  time  with  which  this  project  is  concerned,  we  are  only  interested  in  the 
local  minimums  of  this  sine  wave.  These  are  the  points  of  closest  approach,  and  they  can 
be  approximated  by  using  a  second  order  parabolic  function  as  described  in  equation 
3.33.  Later,  the  accuracy  of  this  approximation  will  be  addressed,  but  for  now,  it  will  be 
assumed  that  this  approximation  is  accurate.  To  find  the  times  at  which  this  intersection 
will  occur,  the  error  angle  can  be  brought  inside  the  quadratic: 


J3(t)=0  =  ip,  -a)+$At  +  ^ j8Ar ' 

And  the  quadratic  equation  can  then  be  used  to  solve  for  At: 


(3.34) 


(3.35) 


There  will  always  be  two  solutions  for  At.  However,  in  many  cases,  these  solutions  will 
be  imaginary,  because  the  terms  inside  the  square  root  are  negative.  This  would  indicate 
that  the  separation  angle  never  exactly  equals  the  error  angle,  and  thus  never  crosses  it. 

A  second  case  might  consist  of  two  negative  values  for  At,  which  would  imply  that  the 
laser  position  vector  has  already  passed  through  the  satellite  error  cone,  and  is  now 
headed  away.  The  third  case  is  that  there  is  one  positive  root  and  one  negative,  which 
implies  that  the  laser  position  vector  is  currently  in  the  laser  cone.  This  will  be  the  case 
when  P<a,  and  can  be  recognized  before  the  quadratic  roots  are  ever  found.  The  fourth 
case,  in  which  At  has  two  positive  values,  is  the  case  in  which  an  intersection  is  forecast 
to  occur.  These  four  cases  are  summarized  in  Table  3.2. 
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Table  3.2.  The  Meanings  of  the  Quadratic  Roots  for  At 


Quadratic  Roots 

Cause 

Intersection? 

Two  Imaginary  Roots 

Laser  never  close  enough  to 
intersect  the  satellite 

No 

Two  Positive  Roots 

Laser  pos  vector  is  moving 
away  from  satellite 

No 

One  Positive,  One  Negative 

Laser  pos  vector  is  currently 
intersecting  the  satellite 

Yes 

Two  Negative  Roots 

Laser  pos  vector  is  moving 
towards  satellite 

Possibly 

The  first  three  cases  are  fairly  straightforward.  Either  an  intersection  will  occur  or 
it  will  not.  The  fourth  case  however,  demands  a  bit  more  attention.  As  an  input  to  the 
algorithm,  the  Time  of  Laze,  Tl,  describing  the  expected  duration  of  the  laze  is  an 
important  part  of  determining  whether  an  intersection  will  occur.  If  the  intersection  is 
forecast  to  occur  outside  of  the  lazing  window: 

T,<AT  (3.36) 

where  represents  the  closest  time  to  intersect,  then,  in  fact,  an  intersection  is  not  forecast 
to  occur.  If  this  is  not  the  case,  then  a  forecasted  intersection  has  occurred. 

3.7.4  Accuracy  of  the  Forecast  Method 

As  mentioned  previously,  the  method  used  to  forecast  the  separation  angle  does 
not  model  the  separation  of  the  laser  and  satellite  position  vectors  accurately  in  all 
situations.  An  example  of  an  inaccuracy  in  the  Forecast  Method  is  illustrated  in  Figure 
3.8.  This  figure  shows  the  actual  separation  angles  encountered  in  “close  approach”  of  a 
satellite  with  the  laser  position  vector.  The  “true  angle”  was  compiled  by  actually 
interpolating  the  platform,  laser,  and  satellite  forward  slowly  in  time,  and  plotting  the 
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separation  angle,  at  each  point  in  time.  The  reason  this  is  established  as  the  “actual 
separation  angle”  is  that  the  positions  of  each  of  the  players  is  fairly  well  known  at  a 
given  time,  and  therefore  P  is  equally  definite.  The  unknown  is  how  well  our  function. 


Separation  Angle  Forecast  During  a  Close 

Approach 


- Actual  Angle 

-  -  -  -  Forecast  Angle 

-  «  "Error Angle 


Figure  3.8.  Comparing  the  Actual  Separation  Angie  Encountered  in 
a  Close  Approach  With  the  Forecasted  Separation  Angle 
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that  uses  $  and  P  to  anticipate  its  behavior,  maps  to  the  known  behavior  of  p.  In  the  case 

of  Figure  3.8,  the  error  angle  was  small,  only  about  0.075  degrees.  Notice  that  at  the  time 
t=0  seconds  into  the  forecast,  the  forecast  angle  and  the  actual  separation  angle 
correspond  almost  perfectly.  In  fact  the  forecast  angle  matches  the  actual  angle  almost 
exactly,  until  5  seconds  before  the  closest  approach,  at  which  time  it  diverges  ever  more 
rapidly.  Unfortunately,  this  is  the  period  of  time  with  which  we  are  most  concerned!  The 
reasons  for  this  divergence  are  interrelated.  First,  we  are  not  using  an  approximation 
function  that  does  not  match  exactly  with  the  behavior  of  the  actual  angle.  Second, 
during  the  time  of  closest  approach,  the  initial  conditions  no  longer  predict  the  separation 
angle  well.  At  this  closest  approach,  the  acceleration  of  the  separation  angle  increases 
dramatically,  due  in  large  part  to  the  proximity  of  the  two  vectors  as  they  pass  each  other. 
This  dramatic  acceleration  is  seen  in  the  rounded  vertex  of  the  actual  separation  angle. 
However,  with  the  forecast,  the  acceleration  remains  minimal,  pushing  the  forecast  to 
actually  intersect  with  the  satellite  at  zero  degrees  of  separation.  This  is,  of  course,  a 
virtual  statistical  impossibility,  and  should  raise  considerable  suspicion  as  to  the  veracity 
of  the  forecast.  In  fact  it  is  to  be  expected  that  the  forecast  angle  will  deviate  from  the 
actual  separation  angle  in  every  forecast,  as  the  initial  conditions  will  eventually  no 
longer  match  actual  conditions  to  the  precision  we  require.  For  example,  consider  the  20- 
second  forecast  shown  in  Figure  3.9.  This  forecast  deals  with  a  satellite  position  vector 
that  never  gets  closer  than  40  degrees  from  the  laser  position  vector.  In  this  plot,  it  can  be 
seen  that  the  forecast  occurred  at  a  time  when  the  two  vectors  where  actually  separating 
from  each  other.  Despite  their  distance  from  each  other,  still  the  forecast  deviates  over 
time,  as  expected.  So  what  does  it  profit  to  use  this  forecasting  method? 
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Degrees 


The  benefit  of  using  this  method  to  pinpoint  intersections  is  that,  in  almost  every  case,  the 
forecast  will  be  conservative  in  its  estimation  of  an  intersection,  and  will  locate  the 
closest  approach  time  to  within  2  seconds  of  the  actual  closest  approach  time. 


Separation  Angle  Forecast  for  Far  Approach 


Seconds  From  Forecast 


Figure  3.9.  Illustration  of  Forecasted  Angle  Deviation  From  Actual 
Angle  in  a  “Far  Away”  Satellite 


Furthermore,  the  forecast  will  eliminate  all  but  the  most  closely  approaching  satellite 
vectors.  Of  course  the  extent  to  which  other  satellites  are  eliminated  by  the  forecast 
depends  heavily  upon  the  initial  conditions.  For  example,  having  a  laser  turret  slew  rate 
of  10  degrees  per  second  is  likely  to  produce  quite  a  few  more  “close-approach” 
satellites,  like  the  one  illustrated  in  Figure  3.8,  than  would  a  normal  operational  turret 
slew  rate  of,  say,  1.5  degrees  per  second  or  less.  Given  the  operational  conditions,  and 
the  turret  slew  rates  necessary  to  track  a  missile  moving  a  roughly  3  kilometers  a  second 
at  100  kilometer  range,  it  would  be  reasonable  to  expect  that  the  turret  would  normally 
track  at  a  rate  of  one  to  two  degrees  per  second.  At  this  rate,  it  is  also  reasonable  to 
expect  that  the  forecast  method  will  eliminate  at  least  90%  of  the  satellites  in  the  list  fed 
to  it.  This  leaves  us  with,  at  most,  10%  of  the  satellites  given  to  the  Main  Processor  that 
must  be  evaluated  more  closely. 

3.8  Interpolation  to  Correct  the  Forecast 

Now  we  have  employed  two  filters  to  narrow  the  list  of  at-risk  satellites.  The 
first,  the  ABLPA  Preprocessor,  can  be  expected  to  eliminate  roughly  75  of  every  100 
satellites  in  an  operational  environment,  depending,  to  some  degree,  upon  the  location  of 
the  theater  employment.  If  we  start  with  the  assumption  that  there  are  1000  active 
satellites,  this  now  leaves  250  to  evaluate.  The  second  filter,  the  Forecast  Filter,  can  be 
expected  to  strain  90%  of  the  remaining  250  and  leave  us  with,  at  most,  25  at-risk 
satellites.  With  so  few  satellites  remaining,  it  now  becomes  feasible  to  use  straight 
interpolation  of  the  separation  angle  for  these  few  satellites  over  a  given  period  of  time. 
Fortunately,  the  Forecast  Filter  also  gives  a  good  approximation  for  the  time  at  which  the 
vertex,  or  the  closest  approach  point  of  the  satellite  position  vector  to  the  laser  position 
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vector,  occurs.  Knowing  this,  an  interpolation  can  be  set  up  using  an  Interpolation  Time 
Buffer  and  Interpolation  Step  Size  as  the  parameters  controlling  the  interpolation. 


3.8.1  The  Interpolation  Time  Buffer 

Starting  with  the  vertex,  a  time  increment  can  be  specified  as  a  certain  interval 
before  the  forecasted  vertex  at  which  to  begin  interpolation.  The  vertex  arrived  at  during 
the  forecast  does  not  necessarily  occur  at  the  time  of  closest  approach.  For  example. 
Figure  3.10  illustrates  the  situation  that  will  occur  in  almost  all  cases. 


Figure  3.10.  Typical  Early  Vertex  Forecast  with  a  Two  Second 

Interpolation  Buffer 

In  the  t5^ical  forecast,  when  the  satellite  and  laser  approach  each  other  within  a  few 
degrees,  the  actual  separation  angle  will  look  fairly  linear  until  a  few  seconds  before  the 
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closest  approach,  much  like  a  triangle  with  a  rounded  bottom  comer.  This  is  seen  clearly 
in  the  example  given  in  Figure  3.8.  With  this  type  of  function  curve,  typically  the 
forecast  vertex  will  occur  slightly  before  the  actual  vertex  in  time.  This  is  seen  in  Figure 
3.10.  So  why  not  simply  begin  interpolation  at  the  forecast  vertex  and  move  forward 
until  the  actual  vertex  is  encountered?  There  are  cases  where  the  forecast  vertex  falls 
after  the  actual  vertex  in  time.  The  first  case  can  occur  if  our  forecast  is  done  near  the 
vertex,  before  crossing  the  error  angle.  This  is  illustrated  in  Figure  3.1 1.  Here,  the 


Figure  3.11.  Special  Case  Forecast  Where  Forecast  Vertex  Falls  After 

Actual  Vertex  in  Time 


forecast  occurs  at  a  critical  time  near  the  vertex,  but  before  the  separation  angle  is  below 
the  error  angle,  so  an  initial  check  will  not  show  the  intersection,  and  the  forecast  will  lie 
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beyond  the  actual  vertex.  It  is  for  cases  like  this  that  a  time  buffer  should  be  inserted 
between  the  forecast  vertex  and  the  interpolation  start  time,  to  ensure  that  the 
interpolation  covers  a  big  enough  time  block  to  include  the  actual  vertex.  Another  case 
that  may  allow  the  forecast  vertex  to  occur  before  the  actual  one,  is  the  case  when  the 
error  angle  is  much  bigger.  The  example  in  Figure  3.10  is  using  an  error  angle  that, 
although  it  is  not  labeled,  would  be  only  about  0. 1  degrees.  According  to  earlier  analysis, 
however,  it  is  anticipated  that  error  angles  of  up  to  1.15  degrees  may  be  anticipated  for 
LEO  satellites.  This  will  raise  the  possibility  of  a  separation  function  that  intersects  the 
error  angle  at  a  higher  degree.  Such  an  event  would  cause  the  forecast  to  drift  to  the  right 
of  the  actual  intersection.  A  third  case  could  occur  where  both  case  1  and  2  happen, 
pushing  the  forecast  even  further  ahead  in  time,  although  this  is  only  a  very  remote 
possibility.  The  best  time  buffer  to  use  is  best  left  to  the  analyst  who  is  using  the 
algorithm.  However,  in  this  project,  the  time  buffer  was  kept  at  two  seconds.  This  buffer 
size  allowed  the  algorithm  to  handle  every  variation  and  case  that  was  run,  without 
exception.  This  is  not  to  say,  however,  that  a  case  does  not  exist  in  which  two  seconds  is 
insufficient.  For  this  reason,  the  time  interpolation  buffer  length  is  an  input  to  the 
software,  as  opposed  to  a  constant. 

3.8.2  Interpolation  Step  Size 

Another  time  increment,  the  interpolation  step  size,  must  also  be  specified.  The  step  size 
refers  to  the  amount  of  time  that  transpires  between  samplings  of  the  separation  angle.  It 
is  the  step  size  that  determines  the  precision  of  the  interpolation.  If  the  step  size  is  too 
big,  then  the  true  vertex  may  never  be  reached  with  enough  precision  to  determine 
whether  or  not  it  crosses  the  error  angle  boundary.  This  is  the  case  in  Figure  3.12.  In  this 
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figure,  the  step  size  is  one  second.  It  can  be  seen  that,  although  the  separation  angle 
crosses  the  error  angle.  The  interpolated  parabola  never  crosses  the  critical  angle,  and 
thus  the  intersection  is  never  registered. 


The  obvious  cure  for  this  problem  is  to  shorten  the  step  size.  However,  this  must  be  done 
with  care.  Each  step  represents  a  complete  analysis  of  the  extent  of  Earth’s  rotation, 
platform  movement,  laser  turret  tracking  and  a  call  to  SGP4  (or  another  ephemeris 
propagator)  to  find  the  separation  angle.  If  the  step  size  is  reduced  from  one  second  to 
0.0001  seconds,  then  we  have  increased  the  number  of  analyses  by  a  factor  of  ten 
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thousand  (per  satellite)!  Our  dilemma  then,  is  to  find  the  step  size  with  enough  precision 
to  satisfy  requirements.  Figure  3.13  presents  the  same  parabola  as  in  Figure  3.12,  but 
with  exactly  one-half  the  step  size.  Fortunately,  the  precision  increases  significantly  as 
the  step  size  decreases. 


Figure  3.13.  Decreasing  Step  Size  Increases  Precision 

This  project  was  tested  with  a  step  size  of  0.1  seconds.  This  increment  caught  every 
satellite  correctly  for  every  operational  scenario  tested.  Again,  this  is  not  to  say  that  01 
seconds  is  necessarily  the  optimum  increment,  only  that  it  worked  flawlessly  during 
testing. 
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3.9  Main  Processor  Methodology  Conclusion 


With  this  summary  the  theory  and  methodology  used  in  this  Predictive  Avoidance 
project  is  concluded.  While  the  previous  pages  focus  on  the  algorithm  that  was 
developed  for  this  project,  Chapter  IV  -  Software  Development  will  attempt  to  describe 
the  actual  application  of  this  algorithm  in  a  software  development  project.  Analysis  of 
the  algorithms  presented  in  these  last  two  chapters  shall  be  fully  addressed  in  Chapter  V  - 
Analysis  and  Conclusions. 
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IV.  Software  Development 


The  software  by  which  the  algorithms  discussed  previously  can  be  used 
practically  is  discussed  briefly  in  this  chapter.  For  a  more  comprehensive  discussion  of 
the  software  implementation,  the  reader  may  wish  to  refer  to  Appendices  A-F.  The 
Predictive  Avoidance  software  has  been  written  with  the  intent  that  it  may  be  used  within 
the  fire  control  system  of  the  Anti-Ballistic  missile  Laser  (ABL)  currently  being 
developed  by  the  Boeing  Corporation.  The  software  has  been  written  in  a  modular 
format,  and  has  been  broken  into  logically  functional  modules  that  have  been  designed  to 
work  both  together  and  independently,  if  needed.  As  mentioned  in  the  Introduction,  this 
software  package  has  been  designed  with  three  conflicting  (but  important)  objectives. 
The  first  objective  is  to  make  the  software  readily  understandable  to  a  person  who  wishes 
to  study  it  in  the  future.  The  package  is  designed  with  an  agreement  by  Boeing  that  it 
will  be  studied  and  at  least  partially  incorporated  directly  into  the  BC/FC  of  the  ABL 
platform.  Therefore,  to  ensure  a  smooth  incorporation  into  the  ABL  project,  the  most 
important  consideration  is  that  an  engineer  can  survey  the  code  and  easily  understand  its 
content  and  purpose.  The  second  goal  is  that  the  software  be  fast.  It  is  estimated  that  the 
prediction  avoidance  software  should  not  need  more  than  0.5  seconds  to  fully  process  a 
mission.  Therefore  algorithms  should  be  designed  to  minimize  processing  time.  The 
third  major  goal  for  the  PA  software  is  that  it  should  be  modular.  Of  these  three  goals  for 
the  software,  understandability  is  the  by  far  the  most  important.  There  are  many  cases 
within  the  software  in  which  a  fluid,  slow,  understandable  implementation  has  been  used 
instead  of  a  speedier  vague  implementation.  This  is  done  with  the  understanding  that  the 
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software  will  be  reviewed  at  a  later  time,  when  any  “slow”  algorithms  may  be  supplanted 
with  the  software  engineer’s  choice  of  implementations.  The  standard  flow  of  the 
software  is  shown  in  Figure  4.1. 


A  TLEFile  containing 
the  satellites  that  have 
been  determined  will 
intersect  the  laser  in  a 
given  time. 


TLE  Input  File  Frcxn 
Space  Command 

(All  Active  Satellites) 


Situation  Inputs 
Time,  Platform 
Position,  etc. 


ABLPA 

Preprocessor 

ABLPA 

Preprocessor 

— ^ 

Output 

- 1 

Main  Processor 

A  TLEFile  containing 
only  those  satellites  that 
are  in  view  of  the 
platform  during  a  given 
time  period. 


Close  Approach 
File 


A  TLEFile  containing 
the  satellites  that  are 
close  enough  to 
interpolate. 


Figure  4.1.  The  Predictive  Avoidance  Software  Flow 


4.1  Modularity  and  Testing 

As  mentioned  previously,  modularity  is  a  goal  for  this  software  package. 
Although  the  software  package  has  been  broken  into  two  separate  entities,  namely  the 
Preprocessor  and  the  Main  Processor,  the  modules  that  compose  this  project  have  been 
grouped  together  into  twelve  smaller  libraries,  by  their  logical  functionality.  The  reason 
for  this  breakdown  is  simple.  The  project  as  a  whole  is  difficult  to  test  as  a  whole. 
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Breaking  down  the  project  into  twelve  testable  mini-projects  allows  independent  testing 
of  a  portion  of  the  software  while  divorcing  it  from  the  whole.  The  benefits  to  this  are 
intuitively  obvious.  Understandability  and  testability  are  increased,  however,  creation  of 
this  type  of  infrastructure  in  the  project  has  also  required  that  the  code  be  that  much 
larger,  with  more  physical  modules  and  interfaces.  Each  library  is  distinguished  by 
having  its  own  stand-alone  GUI  that  calls  the  module(s)  being  used  in  that  library.  As 
implied  before,  there  will  be  twelve  software  libraries  total.  Two  of  these  will  be  the 
final  ABLPA  Preprocessor  and  Main  Processor.  The  other  ten  will  be  composed  of  lower 
and  lower  levels  of  subordinate  modules;  five  testing  modules  in  the  Preprocessor,  and 
five  more  introduced  in  the  Main  Processor.  The  overall  structure  of  the  software  is 
addressed  with  more  depth  in  Appendix  A  -  Software  Structure. 

4.2  The  Calculation  Modules 

The  modules  that  house  the  meat  of  the  algorithm  and  the  calculation  intensive 
software  are  written  in  the  C++  language.  The  compiler  used  is  Borland  C++  Builder  3 
(Standard,  C++  Version  5).  It  is  likely  that  the  code  for  these  modules  can  be  recompiled 
with  minimal  effort  using  another  similar  C++  compiler.  These  modules  are  written  for 
easy  adaptability  to  other  environments.  All  of  the  code  for  the  calculation  modules  will 
be  included  and  discussed,  as  its  explanation  and  operation  is  one  of  the  important 
products  that  this  thesis  delivers.  Appendix  B  -  The  ABLPA  Preprocessor  Software  will 
discuss  all  modules  developed  for  the  ABLPA  Preprocessor.  Appendix  C  -  The  ABLPA 
Main  Processor  Software  will  discuss  modules  developed  for  the  Main  Processor  that 
have  not  already  been  covered  in  Appendix  B. 
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4.3  The  Test  Modules  for  Each  Software  Library 


There  are  other  modules  that  have  been  developed  exclusively  for  the  task  of 
calling  and  interfacing  with  the  Preprocessor  the  Main  Processor,  and  each  of  the  other 
ten  libraries.  They  are  strictly  “front-end”  interfaces  for  the  calculation  modules  that  can 
be  used  to  run  and  test  the  algorithms  that  have  been  developed  within  the  calculation 
modules.  These  test  modules  have  been  kept  as  “simple”  as  possible,  while  still 
maintaining  ease-of-use,  to  avoid  the  necessity  of  “testing”  the  test  modules.  They 
consist  of  a  graphical  interface  that  collects  input  to  the  module(s)  being  tested,  and  the 
function  call  to  those  modules.  The  graphical  nature  of  the  test  modules  utilizes  quite  a 
bit  of  compiler-specific  organization  and  terminology  to  allow  easy  development  of  these 
modules.  Therefore,  any  change  or  recompilation  of  these  graphical  interface  modules 
will  require  the  user  to  have  a  copy  of  Borland  C+-i-  Builder  3  (Standard).  This  compiler 
will  also  be  required  if  the  user  of  this  software  wishes  to  run  the  fully  compiled  software 
packages  that  have  included  within  them  the  GUI  interfaces.  The  Test  Modules  and  their 
software  code  is  described  further  in  Appendix  E. 

4.4  The  Environment 

These  modules  have  all  been  developed  using  a  standard  desktop  IBM  compatible 
computer,  using  a  200  MHz  Intel  Pentium  processor.  The  modules  are  compiled  to  run  in 
the  Microsoft  Windows  95  or  98  operating  system  environment.  Operation  in  other 
environments  has  not  been  tested  and  is  not  guaranteed,  especially  the  graphical  test 
modules. 
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4.5  Sample  Interfaces 


As  mentioned  previously,  the  product,  C++  Builder  3.  made  by  Borland  was  used 
to  craft  a  graphical  front-end  to  each  application  designed.  One  GUI  has  been  created  for 
each  functional  task  (or  library)  needed  in  the  Preprocessor  and  Main  Processor.  Each  of 
these  modules,  where  practical,  comes  with  a  graphical  front-end  interface  to  allow 
testing  of  individual  components.  Both  the  Preprocessor  and  the  Main  Processor  have 


Figure  4.2.  GUI  Interface  to  the  Preprocessor 


similar  interfaces.  The  Preprocessor  interface  is  shown  in  Figure  4.2.  the  inputs  and 
outputs  can  be  clearly  seen  and  modified  using  this  interface.  It  should  be  noted  that 
these  interfaces,  although  easy  to  use,  will  almost  certainly  not  be  included  in  the  final 
software  package  to  be  used  on  board  the  ABL  platform.  They  take  up  far  too  much 
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Figure  4.3.  GUI  interface  to  the  Main  Processor 


overhead  processing  to  be  practical,  and  it  is  likely  that  the  PA  software  will  be  executed 
automatically,  at  laze  time,  not  using  a  man/machine  graphical  interface.  Rather,  the 
main  purpose  of  these  interfaces  is  to  allow  an  easier  testing  environment  in  which 
parameters  can  be  changed  quickly  and  output  can  be  seen  in  a  formatted  framework. 
The  interface  to  the  Main  processor  is  similar  to  that  of  the  Preprocessor,  and  can  be  seen 
in  Figure  4.3.  Again,  Appendices  A-F  will  provide  a  more  complete  description  of  the 
modules,  interfaces,  inputs  and  outputs  for  the  software  package  discussed  briefly  here. 
An  analysis  of  the  software  will  follow  in  Chapter  V. 
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V.  Analysis  and  Conclusions 


Now  that  the  methodology  of  the  Predictive  Avoidance  algorithm  has  been 
developed  and  discussed,  and  software  has  been  created  to  automate  this  algorithm,  we 
must  now  evaluate  whether  or  not  all  of  the  goals  of  this  study  have  been  achieved.  The 
reader  will  recall  that  the  two  main  goals  of  this  study  were  to  develop  a  predictive 
avoidance  algorithm,  and  to  develop  a  software  system  that  can  automate  this  algorithm 
using  less  than  0.5  seconds  during  the  pre-laze  fire  sequence.  The  analysis  of  the 
software  in  the  following  sections  addresses  how  well  the  algorithm  and  software  meets 
these  goals.  Areas  where  there  may  be  room  for  improvement  will  also  be  discussed. 
Due  to  time  constraints,  the  optimal  solution  to  some  problems  encountered  in  this 
project  may  have  been  bypassed  by  using  more  convenient  methods.  Although  it  is 
hoped  that  there  are  not  many  such  areas,  some  were  a  necessity  to  ensure  this  product 
was  delivered  on  time.  Recognizing  that  this  thesis  is  only  the  first  draft  of  an  iterative 
process  conducted  by  Boeing,  it  is  hoped  that  these  “lacking”  areas  will  be  further  studied 
and  refined  in  future  iterations. 

5.1  Software  Analysis  and  Performance 

Numerous  tests  were  conducted  upon  each  software  library  module  individually, 
and  upon  the  integrated  Preprocessor  and  Main  Processor.  For  brevity,  the  individual 
module  testing  will  not  be  discussed  except  to  say  that  individual  test  cases  were 
compiled  to  analyze  each  module,  including  extensive  boundary  and  critical  value 
testing.  Each  module  was  required  to  pass  all  test  cases  before  being  integrated.  It  must 
be  stressed  here  that  SGP4  was  heavily  relied  upon,  but  not  tested.  This  is  the  only 
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module  that  was  not  tested,  because  of  its  complexity,  historical  verification,  and 
difficulty  of  independent  verification  and  validation. 

5.1.1  Integration  Testing 

After  each  module  was  independently  tested  and  verified,  the  integrated 
Preprocessor  and  Main  Processor  were  tested  using  interface  and  boundary  tests  that 
ensured  the  outputs  received  during  individual  module  testing  were  being  integrated  into 
the  proper  format,  without  corrupting  data  across  the  interfaces.  Final  integration  testing 
included  roughly  2,000  -  2,500  individual  executions  of  both  the  Preprocessor  and  the 
Main  Processor.  Only  approximately  100  of  these  runs  were  used  to  verify  (via 
independent  calculations)  the  correctness  of  the  output.  These  100  runs  incorporated 
changes  in  the  location  of  the  platform,  speed,  turret  rates,  and  times  of  laze.  It  is  not 
beneficial  to  list  every  test  here,  as  the  software  needs  to  be  verified  by  an  independent 
third  party  regardless.  However,  the  performance  of  the  software  in  general,  and 
performance  under  some  tests  will  be  briefly  discussed. 

5.1.2  Preprocessor  Software  Filtering  Performance 

A  sample  TLE  satellite  input  file  was  used  containing  772  unclassified  satellite 
listings.  The  Preprocessor  found,  on  average,  that  22%  of  these  input  satellites  were  in 
view.  By  changing  the  location  of  the  platform  and  the  Universal  Time  of  execution, 
testing  concluded  that  the  maximum  number  of  satellites  ever  deemed  in  view  of  the 
platform  was  209  (or  27.1%)  at  the  location  5°  Latitude,  100°  Longitude,  on  August  14, 
1998,  03:58  AM  GMT.  Of  course,  not  every  time  and  location  were  tested,  and  so  this 
maximum  percentage  might  rise  slightly,  but  not  much.  The  fewest  number  of  satellites 
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seen  in  view  is  78  (or  10.1%)  at  the  South  Pole  during  the  same  time  slot.  Of  course,  the 
polar  caps  are  not  of  great  interest,  as  it  is  unlikely  that  the  ABL  will  ever  see  the  poles, 
and  a  polar  location  precludes  the  possibility  of  encountering  any  satellites  within  the 
Geostationary  Belt. 

5.1.3  Preprocessor  Software  Timing  Performance 

Given  the  input  file  of  772  satellites,  the  Preprocessor  executed,  on  average,  in  1.2 
seconds  Wall  Clock  Time  (WCT).  This  test  was  conducted  on  a  standard  200  MHz  IBM 
compatible  desktop  computer,  running  under  the  Microsoft  Windows  98  OS.  The  WCT 
differed  between  0.9  and  1.8  seconds,  depending  upon  the  CPU  load  exerted  by  other 
applications  at  the  time  of  the  test.  WCT  will  depend  heavily  upon  the  system  used  to 
run  the  Preprocessor.  Although  the  Preprocessor  is  not  required  to  run  within  a  given 
time  budget,  it  is  good  to  know  that  it  is  fairly  quick  and  can  be  run  multiple  times  in  a 
minute,  if  needed.  The  graphical  interface  and  the  input/output  files  constitute  a  large 
part  of  this  WCT.  It  is  clear  that  WCT  will  be  substantially  reduced  when  the  GUI  is 
stripped  off,  and  the  I/O  is  handled  in  memory  rather  than  through  disk  read/writes. 

5.1.4  Main  Processor  Software  Filtering  Performance 

For  a  given  sample  test,  where  the  platform  was  located  at  0°  Latitude,  0° 
Longitude,  the  sample  TLE  satellite  input  file  was  used,  containing  772  unclassified 
satellite  listings.  This  is  the  file  that  the  Main  Processor  would  encounter  if  no 
Preprocessing  was  accomplished  ahead  of  time.  The  Main  Preprocessor  found  that  17  (or 
2.2%)  of  these  input  satellites  were  close  enough  to  interpolate  (17  satellites  were 
interpolated).  By  changing  the  location  of  the  platform  and  the  Universal  Time  of 
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execution,  testing  concluded  that  the  maximum  number  of  satellites  ever  close  enough  to 
be  interpolated  was  18  (Or  2.3%  of  the  active  satellite  file),  so  this  sample  test  is 
approaching  the  maximum  number  of  close-approach  satellites  that  have  been  seen  in  any 
test.  Again,  not  every  time  and  location  were  tested,  and  so  this  maximum  number  may 
be  exceeded  somewhere,  but  not  by  much.  When  preprocessing  is  performed,  the  input 
file  to  the  Main  Processor  drops  to  198  satellites  (the  satellites  that  are  in  view),  which  is 
still  a  somewhat  high  concentration.  When  the  Main  Processor  analyzed  this  new  input 
file,  it  found  16  (rather  than  the  expected  17)  close-approach  satellites.  It  is  expected  that 
the  number  of  close-approach  satellites  should  not  change,  because  preprocessing  only 
strips  away  satellites  that  could  not  possibly  intersect  the  laser.  The  reason  for  this 
discrepancy  is  that  one  of  the  17  satellites  that  was  forecast  to  intersect  the  laser  was  on 
the  other  side  of  the  Earth,  but  during  the  exact  moment  of  the  forecast  was  accelerating 
at  a  very  fast  rate  toward  the  laser.  When  this  fast  acceleration  (which  in  reality  lasts 
only  fractions  of  a  second)  is  propagated  30  seconds  into  the  future,  it  results  in  an 
unrealistic  forecast  that  is  quickly  weeded  out  using  interpolation.  At  no  time  during 
random  testing  was  an  actual  intersection  recorded.  Rather  the  intersection  tests  had  to 
be  engineered  and  manipulated  by  the  tester,  because  of  the  extremely  low  probabilities 
of  an  actual  intersection.  There  were  no  test  cases  developed,  engineered  or  random,  that 
could  produce  more  than  one  intersected  satellite. 

5.1.5  Main  Processor  Software  Timing  Performance 

Given  the  unprocessed  input  file  of  772  satellites,  the  Main  Processor  executed, 
on  average,  in  0.9  seconds  WCT.  This  test  was  conducted  on  the  same  computer  as  the 
Preprocessor.  When  given  the  preprocessed  file  of  198  in-view  satellites,  the  Main 
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Processor  execution  time  dropped  down  to  0.25  seconds  WCT.  Again,  WCT  will  be 
substantially  reduced  when  the  GUI  is  stripped  off,  and  the  faster  memory  I/O  is  used. 
The  reader  will  recall  that  the  requirement  for  execution  is  0.5  seconds,  so  there  is  plenty 
of  room  for  additions/modifications  to  the  software. 

5.2  Further  Study 

There  are  a  number  of  areas  that  may  require  further  study,  and  have  not  been 
thoroughly  considered  in  this  thesis.  It  is  hoped  that  these  topics  will  be  addressed  during 
future  iterations  in  the  development  of  the  final  software  package  to  be  used  with  the 
ABL  platform.  These  topics  are  only  briefly  addressed  here. 

5.2.1  Missile  Tracking 

Currently,  the  software  treats  the  missile  trajectory  as  a  static  entity,  with  initial 
parameters  that  do  not  change.  This  is  reflected  in  the  laser  turret  position,  velocity  and 
acceleration  variables  which  are  read  at  forecast  time,  and  held  constant  throughout  the 
forecast  duration,  as  long  as  thirty  seconds.  It  is  unreasonable  to  believe  that  these 
parameters  cannot  vary  while  the  missile  is  in  the  boost  phase.  Different  ballistic  missile 
systems  have  bum  rates  that  vary  significantly  throughout  the  duration  of  the  burn. 
While  the  initial  acceleration  may  not  change,  there  is  also  a  good  probability  that  it  will 
change.  A  significant  change  from  initial  conditions  will,  of  course,  invalidate  a  forecast 
that  is  based  on  those  initial  conditions.  There  are  at  least  two  feasible  methods  to 
counter  this  variance  from  initial  conditions.  The  first  method  is  to  store  another  data  file 
that  accurately  describes  the  bum  rates  of  all  possible  missile  targets,  and  use  this 
information  to  more  accurately  predict  missile  trajectory.  The  second  suggested  method 
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is  to  simply  rerun  the  Main  Processor  when  and  if  the  actual  conditions  change  from  the 
initial  conditions  by  some  slight  error  angle,  and  then  include  that  slight  error  angle  in  the 
forecast  error  angle  already  computed  for  the  scenario.  Using  this  method,  the  Main 
Processor  would  re-execute  during  the  laze  only  if  the  initial  conditions  are  seriously 
compromised  by  the  actual  missile  trajectory.  Although  there  is  an  extremely  remote 
possibility  that  this  recomputation  could  result  in  laze  interruption,  this  is  unlikely,  given 
the  fact  that  2000  random  runs  of  the  Main  Processor  have  not  produced  a  single 
intersection  yet.  Even  if  an  intersection  was  predicted,  the  decision  to  terminate  the  laze 
still  rests  in  comparing  the  importance  of  the  target  to  the  importance  of  the  compromised 
satellite.  This  second  solution’s  strength  is  that  it  is  easily  implemented  and  tested. 

5.2.2  Atmospheric  Refraction 

As  laser  energy  travels  through  the  atmosphere,  it  encounters  differing 
atmospheric  densities  until  it  reaches  the  relatively  empty  vacuum  of  space.  As  light 
encounters  these  differing  densities,  the  index  of  refraction  of  the  medium  (air)  changes, 
causing  the  leading  edge  of  the  beam  to  travel  at  a  slightly  different  speed  than  the 
trailing  edge.  Over  a  large  distance,  this  can  cause  the  beam  to  arc  (or  refract)  slightly 
until  it  reaches  space.  Quick  calculations  show  that  this  arc  may  cause  as  much  as  a  0.4 
degree  change  within  the  atmosphere  for  small  slant  angles  traveling  a  long  distance 
before  hitting  the  vacuum  of  space.  This  degree  change  would  then  be  further  added  to 
as  the  beam  propagates  at  its  new  trajectory  through  space.  This  refractive  issue  is  a 
challenge  that  was  encountered  too  late  to  incorporate  into  this  iteration,  but  it  is  still 
extremely  important.  The  solution  is,  of  course,  to  account  for  this  refraction  given  the 
location  of  the  platform  and  the  starting  parameters  of  the  laser  turret.  Although  the 
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refractive  index  of  air  varies  from  location  to  location,  for  our  purposes,  it  can  be  held 
constant  over  given  altitudes  with  only  minor  errors  in  the  refraction  calculation. 

5.2.3  Error  Angle  Determination 

Currently,  the  error  angle  for  a  given  satellite  encounter  is  computed  using  rough 
position  error  approximations.  This  results  in  an  error  angle  that  is  an  absolute.  That  is, 
we  can  either  hit  it  or  miss  it.  Further  the  error  angle  describes  a  spherical  comfort  zone 
around  the  satellite  when  in  fact,  the  error  ellipsoid  should  probably  be  more  oblong  and 
eccentric  given  the  types  of  errors  encountered.  One  possible  solution  to  further  define 
the  error  ellipsoid  is  to  use  covariance  matrices  to  model  each  of  the  position  error 
ellipsoids,  resulting  in  a  more  probabilistic  definition  of  the  comfort  zone  around  the 
satellite  that  we  wish  to  avoid.  The  difficulties  with  this  solution  lie  in  the  population  of 
each  covariance  matrix,  and  the  definition  of  exactly  what  probability  is  “too  high”  a  risk 
when  describing  the  approach  of  the  laser  to  the  satellite.  Because  this  solution  would 
have  added  a  significant  time  cost  with  marginal  fidelity  improvement,  it  was  decided  to 
forego  this  method  in  favor  of  the  simpler  half-error  angle  approach. 

5.2.4  Forecast/Interpolation  Fine  Tuning 

Currently  the  Main  Processor  does  a  rough  forecast  that  interprets  more  satellites 
being  intersected  that  are  actually  intersected,  and  then  interpolates  the  position  of  each 
“intersecting”  satellite  to  ensure  that  it  actually  does  intersect.  During  testing  of  the  Main 
Processor,  no  satellites  that  approached  close  enough  to  the  laser  to  possibly  be 
threatened  were  ever  “not  caught”  by  the  initial  forecast.  This  is  not  to  say  that  it  could 
not  happen  however.  Independent  calculations  have  shown  that,  theoretically,  a  small 
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possibility  exists  that  a  LEO  range  satellite  with  a  large  error  angle  could  possibly  slip  by 
if  the  satellites  comfort  zone  (error  angle)  is  just  barely  touched  by  the  laser  turret  angle 
in  the  first  0.3  seconds  after  the  forecast  is  conceived.  In  this  case,  there  is  a  small 
possibility  that  the  initial  conditions  would  be  derived  near  the  vertex,  and  that  the 
forecast  closest  approach  angle  is  predicted  to  occur  long  after  it  actually  has  occurred. 
This  is  a  problem  because  there  is  a  set  “Interpolation  Buffer  Time”  before  the  forecast 
closest  approach  starts  when  the  interpolation  begins.  If  the  time  between  the  forecast 
closest  approach  and  the  actual  closest  approach  is  greater  than  this  buffer  time,  then 
interpolation  will  not  catch  an  intersection  that  occurs  at  the  actual  closest  approach  time. 
This  has  not  occurred  in  any  test  cases,  and  attempts  to  engineer  such  a  case  failed 
repeatedly  due  to  the  time  and  precision  needed  to  model  such  an  approach.  This  is  not 
to  say,  however,  that  it  is  impossible.  A  possible  solution  might  be  to  increase  the  buffer, 
which  only  slightly  affects  the  overall  run-time  (depending  upon  the  step  size).  Further, 
attempts  should  be  made  to  refine  the  interpolation  step  size.  During  testing,  it  became 
evident  that  0.1  seconds  was  adequate  for  the  precision  needed,  without  compromising 
too  much  efficiency.  This  is  not  to  say,  however,  that  0. 1  seconds  is  the  optimum  size, 
nor  that  it  will  catch  every  possible  intersection. 

5.2.5  Software  Speed  and  Testing 

As  mentioned  previously,  this  software  was  not  necessarily  written  to  have  the 
fastest  possible  execution  time.  Rather,  the  primary  goal  was  to  write  the  software  so  that 
it  is  easily  understandable.  This  often  involved  coding  an  algorithm  using  an  inefficient 
implementation  so  that  it  matched  (both  functionally  and  visually)  the  methodology  as  it 
is  presented  in  this  thesis,  rather  than  using  an  elegant  but  fuzzy  solution.  Because  this 
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code  was  designed  and  implemented  with  the  understanding  that  it  would  be  just  the  first 
step  of  an  iterative  solution,  understandability  was  considered  the  highest  priority  to 
ensure  a  successful  handoff.  Testing  is  likewise  considered  to  be  iterative.  Although 
considerable  in-house  testing  was  completed  by  the  author,  it  was  a  one-man  effort.  One 
man  does  not  make  a  very  dynamic  testing  team,  especially  when  that  one  man  is  the 
designer,  coder,  and  verification/validation  checker!  That  man,  though  disciplined,  is 
bound  to  have  his  own  biases  and  iterative  mistakes  that  cannot  be  cross-checked  with 
anyone  else.  Therefore  the  value  of  the  testing  conducted  by  him  is  diminished,  and 
mistakes  are  likely  to  still  exist. 

5.3  Conclusion 

There  has  been  much  ground  covered  here,  and  it  is  hoped  that  the  Predictive 
Avoidance  algorithm  and  its  corresponding  software  will  prove  to  be  usefiil  in  future 
modeling  efforts.  Although  this  thesis  applies  to  a  narrow  application  platform,  namely 
the  ABL,  it  can  be  seen  that  the  general  algorithm  is  broadly  applicable  to  a  wide  range  of 
directed-energy  targeting  applications.  For  instance,  setting  the  platform  speed  and 
altitude  to  zero  will  result  in  a  land-based  model  for  predictive  avoidance.  It  is  likely  that 
directed-energy  weapons  will  become  more  widespread  if  the  technology  can  be 
adequately  exploited  with  the  first  operational  ABL  series.  If  so,  the  general  principles 
tied  together  in  this  thesis  will  find  broader  application. 
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Appendix  A  -  The  Software  Structure 


The  software  implementation  by  which  the  algorithms  discussed  previously  can 
be  automated  is  discussed  in  this  appendix.  This  appendix,  combined  with  the  following 
appendices,  comprise  a  rough  software  programmer’s  manual.  The  software  has  been 
written  in  a  modular  format,  and  has  been  broken  into  logically  functional  modules  that 
have  been  designed  to  work  both  together  and  independently,  if  needed.  As  mentioned  in 
Chapter  IV,  this  software  package  has  been  designed  with  three  conflicting  objectives. 
The  first  objective  is  to  make  the  software  readily  understandable  to  a  person  who  wishes 
to  study  it  in  the  future.  The  second  goal  is  that  the  software  be  fast.  It  is  estimated  that 
the  prediction  avoidance  software  should  not  need  more  than  0.5  seconds  to  fully  process 
a  mission.  The  third  major  goal  for  the  PA  software  is  that  it  should  be  modular.  Of  these 
three  goals  for  the  software,  understandability  is  the  by  far  the  most  important.  There  are 
many  cases  within  the  software  in  which  a  fluid,  slow,  understandable  implementation 
has  been  used  instead  of  a  speedier  vague  implementation.  This  is  done  with  the 
understanding  that  the  software  will  be  reviewed  at  a  later  time,  when  any  “slow” 
algorithms  may  be  supplanted  with  the  software  engineer’s  choice  of  implementations. 
The  standard  flow  of  the  software  is  shown  in  Figure  A.  1 . 

A.l  Modularity  and  Testing 

As  mentioned  previously,  modularity  is  a  goal  for  this  software  package. 
Although  the  software  package  has  been  broken  into  two  separate  entities,  namely  the 
Preprocessor  and  the  Main  Processor,  the  modules  that  compose  this  project  have  been 
grouped  together  into  twelve  smaller  libraries,  by  their  logical  functionality.  The  reason 
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A  TLE  File  containing 
the  satellites  that  have 
been  determined  will 
intersect  the  laser  in  a 
given  time. 


TLE  Input  File  From 
Space  Command 

(All  Active  Satellites) 


Situation  Inputs 
Time,  Platform 
Position,  etc. 


ABLPA 

Preprocessor 

ABLPA 

Preprocessor 

Output 

1 

Main  Processor 

A  TLE  File  containing 
only  those  satellites  that 
are  in  view  of  the 
platform  during  a  given 
time  period. 


A  TLE  File  containing 
the  satellites  that  are 
close  enough  to 
interpolate. 


Close  Approach 
File 


Figure  A.I.  The  Predictive  Avoidance  Software  Fiow 


for  this  breakdown  is  simple.  The  project  as  a  whole  is  difficult  to  test  as  a  whole. 
Breaking  down  the  project  into  twelve  testable  mini-projects  allows  independent  testing 
of  a  portion  of  the  software  while  divorcing  it  from  the  whole.  The  benefits  to  this  are 
intuitively  obvious.  Understandability  and  testability  are  increased,  however,  creation  of 
this  type  of  infrastructure  in  the  project  has  also  required  that  the  code  be  that  much 
larger,  with  more  physical  modules  and  interfaces.  Each  library  is  distinguished  by 
having  its  own  stand-alone  GUI  that  calls  the  module(s)  being  used  in  that  library.  As 
implied  before,  there  will  be  twelve  software  libraries  total.  Two  of  these  will  be  the 
final  ABLPA  Preprocessor  and  Main  Processor.  The  other  ten  will  be  composed  of  lower 
and  lower  levels  of  subordinate  modules;  five  testing  modules  in  the  Preprocessor,  and 
five  more  introduced  in  the  Main  Processor. 
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A.2  The  Calculation  Modules 


The  modules  that  house  the  meat  of  the  algorithm  and  the  calculation  intensive 
software  are  written  in  the  C++  language.  The  compiler  used  is  Borland  C++  Builder  3 
(Standard,  C++  Version  5).  It  is  likely  that  the  code  for  these  modules  can  be  recompiled 
with  minimal  effort  using  another  similar  C++  compiler.  These  modules  are  written  for 
easy  adaptability  to  other  environments.  All  of  the  code  for  the  calculation  modules  will 
be  included  and  discussed,  as  its  explanation  and  operation  is  one  of  the  important 
products  that  this  thesis  delivers.  Appendix  B  -  The  ABLPA  Preprocessor  Software  will 
discuss  all  modules  developed  for  the  ABLPA  Preprocessor,  along  with  their 
corresponding  interface  parameters.  Appendix  C  -  The  ABLPA  Main  Processor 
Software  will  discuss  modules  developed  for  the  Main  Processor  that  have  not  already 
been  covered  in  Appendix  B.  The  actual  implementation  code  listings  for  the  calulation 
modules  is  given  in  Appendix  D  -  Implementation  Code. 

A.3  The  Test  Modules  for  Each  Software  Library 

There  are  other  modules  that  have  been  developed  exclusively  for  the  task  of 
calling  and  interfacing  with  the  Preprocessor  the  Main  Processor,  and  each  of  the  other 
ten  libraries.  They  are  strictly  “front-end”  interfaces  for  the  calculation  modules  that  can 
be  used  to  run  and  test  the  algorithms  that  have  been  developed  within  the  calculation 
modules.  These  test  modules  have  been  kept  as  “simple”  as  possible,  while  still 
maintaining  ease-of-use,  to  avoid  the  necessity  of  “testing”  the  test  modules.  They 
consist  of  a  graphical  interface  that  collects  input  to  the  module(s)  being  tested,  and  the 
function  call  to  those  modules.  The  graphical  nature  of  the  test  modules  utilizes  quite  a 
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bit  of  compiler-specific  organization  and  terminology  to  allow  easy  development  of  these 
modules.  Therefore,  any  change  or  recompilation  of  these  graphical  interface  modules 
will  require  the  user  to  have  a  copy  of  Borland  C+-i-  Builder  3  (Standard).  This  compiler 
will  also  be  required  if  the  user  of  this  software  wishes  to  run  the  fully  compiled  software 
packages  that  have  included  within  them  the  GUI  interfaces.  The  Test  Modules  and  their 
software  code  is  described  further  in  Appendix  E  -  Test  Module  Code. 

A.4  The  Environment 

These  modules  have  all  been  developed  using  a  standard  desktop  IBM  compatible 
computer,  using  a  200  MHz  Intel  Pentium  processor.  The  modules  are  compiled  to  run  in 
the  Microsoft  Windows  95  or  98  operating  system  environment.  Operation  in  other 
environments  has  not  been  tested  and  is  not  guaranteed,  especially  the  graphical  test 
modules. 

A.5  Test  Module  Example 

As  mentioned  previously,  the  product,  C++  Builder  3.  made  by  Borland  was  used 
to  craft  a  graphical  front-end  to  each  library  designed.  One  GUI  has  been  created  for 
each  functional  task  (or  library)  needed  in  the  Preprocessor  and  Main  Processor.  Each  of 
these  modules,  where  practical,  comes  with  a  graphical  front-end  interface  to  allow 
testing  of  individual  components.  This  test  module  example  is  included  to  give  the  user 
an  idea  of  the  design  of  each  front-end.  Each  front-end  is  designed  simply,  without 
contributing  to  the  solution  of  the  algorithm  handled  by  the  module  being  called. 
Because  each  of  these  test  modules  have  little  worth  in  themselves,  I  will  demonstrate 
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how  just  one  of  the  test  modules  work,  and  only  include  a  cursory  graphical  figure  when 
describing  test  modules  in  the  future.  The  module  chosen  to  describe  the  interface  here  is 
the  module  that  interfaces  directly  with  the  SGP4  time  propagation  modules.  This  GUI 
routine  tests  modules  in  the  library  “SGP4Support”.  The  main  calculation  module 
(“CallSGP4”)  is  held  within  “SGP4SupportModules.cpp”.  This  module,  in  turn,  calls  the 
SGP4  routines  created  by  Air  Force  Space  Command,  which  are  held  in 
“SGP4Routines.cpp”.  The  test  module  Graphical  User  Interface  (GUI)  used  to  call  this 
main  routine  is  called  “SGP4TestForm”,  held  in  a  physical  module  of  the  same  name. 
The  graphical  interface  is  shown  in  Figure  A.2. 


Figure  A.2.  GUI  interface  to  the  “SGP4  Support”  Project 
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A.5.1  Description  of  Code 


The  code  for  SGP4TestFonn  is  only  partially  included  here.  A  software 
programmer  will  notice  that  much  of  the  code  infrastructure  is  missing.  This  is  because 
C  Builder  handles  much  of  the  behind-the-scenes  programming  and  leaves  only  the 
event-handlers  for  implementation  by  the  programmer.  So,  in  reality  only  the  event- 
handlers  are  shown  in  the  code  that  follows.  An  “event-handler”  is  anything  that  can  be 
manipulated.  For  instance,  any  button  that  can  be  “pushed”  on  the  GUI  may  have  a  small 
routine,  called  an  event-handler,  which  executes  a  set  of  instructions.  Having  only  the 
event  handlers  in  a  condensed  piece  of  code  allows  the  maintainer  to  easily  grasp  and 
change  the  nature  of  the  GUI.  There  are  a  few  things  to  point  out  in  the  code  that 
follows.  First,  there  are  two  main  event-handlers  associated  with  this  GUI.  Their  names 
are  “FileButtonClick”  and  “RunButtonClick”.  This  is  appropriate  because  the  GUI 
template  in  Figure  A.  1  has  exactly  two  buttons  that  can  be  pushed.  The  First  button  is  the 
“Propagate  Using  File”  button  that  activates  the  “FileButtonClick”  event-handler,  the 
second  is  the  “Run  SGP4  (Versions  .01)”  button  that  activates  the  “RunButtonClick” 
event-handler.  Notice  that  each  routine  is  fairly  simple  and  straight-forward.  There  is  no 
attempt  to  solve  any  part  of  the  Predictive  Avoidance  algorithm  within  the  event-handler 
itself.  Rather,  they  simply  make  a  call  to  the  routines  that  do  the  work.  The  sole  purpose 
of  the  event-handler  is  to  take  inputs,  call  a  calculation  module,  and  format  the  resulting 
output.  For  instance,  RunButtonClick  simply  calls  the  module  “CallSGP4”. 
FileButtonClick  calls  “ReadTLEFile”.  So  these  test  GUIs  can  be  seen  to  be  simply 
interfaces  that  allow  easy,  extensive  testing  of  the  calculation  modules,  which  house  the 
meat  of  the  project.  The  code  follows  on  the  next  few  pages. 
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A.5.2  Code  Listing  for  SGP4TestForm 


/*★*★★*★***★*******************★*★*******************★*******★***************/ 
/*  MODULE  NAME:  SGP4TestForin.  cpp  */ 

/*  AUTHOR:  Captain  David  Vloedman  */ 

/*  DATE  CREATED:  October  10, 1998  */ 

/*  */ 

/*  PURPOSE:  This  test  form  module  is  a  test  module  for  the  routines  */ 

/*  handle  calling  of  the  satellite  propagator.  ''SGP4".  This*/ 

/*  propagator  is  US  Space  Command's  satellite  time/position*/ 

/*  propagator  using  general  perturbations  only.  The  */ 

/*  version  of  SGP4  used  here  is  version  3.01  in  C  */ 

/*  */ 

/*  */ 

/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 


/****★*★***★****★**★★****************★***★*★*****★***★*★*★*******************/ 

/***************★*****★**★***★****/ 

/*  C++BUILDER-SPECIFIC  LIBRARIES  */ 

/*********************************/ 

# inc lude  < vc 1 . h> 

#pragma  hdrstop 

#pragma  package (smart_init) 

#pragma  resource  " * . dfm" 

/*******★****★*********★*★*****★**/ 

/*  USER-BUILT  LIBRARIES  */ 

/*******★****★★*******************/ 

# include  "SGP4TestForm.h" 

# include  " SGP4SupportModules .h" 

#include  " LaserConstants . h ” 

#include  "Satellite .h" 

#include  "ErrorStructure.h” 

# inc lude  "TLEInput .h" 

/**★********★*****★★*********★****/ 

/*  C  STANDARD  LIBRARIES  */ 

/*★********★**********************/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <string.h> 

#include  <iostream.h> 

# include  <conio.h> 

# include  ''SGP4Routines  .h" 

#include  "TimeModules . h" 

/★******************★********★**/ 

/*  CREATE  THE  FORM  */ 

/*****★**★★***********★****★★***/ 

TForml  *Forml ; 

// - - - - - 

_ fastcall  TForml :: TForml (TComponent*  Owner) 

:  TForm( Owner) 

{ 

) 

/*****★**★*****************★******•**★**********★****/ 

/*  THIS  EVENT  HANDLER  PROCEDURE  HANDLES  THE  BUTTON*/ 

/*  THAT  CAN  LOAD  A  TEST  CASE  FROM  A  FILE  FOR  LATER*/ 

/*  EXECUTION  */ 

/******★**★*★*★***********★*★**********★*****★**★***/ 

void _ fastcall  TForml :: FileButtonClick (TObj ect  *Sender) 

{ 


Errors true ture  ErrorList; 

SatStructure  *SatArray  =  new  SatS true ture; 

char  Errors [MAXERRORS] [MAXMESSAGELENGTH] ; 
int  i; 

Errors true ture  *ErrorPtr=&ErrorList ;  /*  A  POINTER  TO  ERRORLIST  */ 
char  FileNamelMAXNAMELENGTH]  =  ” 


/*********★★*****************★*★******★*★***★*******/ 

/*  GET  NAME  OF  FILE  TO  READ  TEST  CASE  FROM  */ 

/*************★**************************★**********/ 
strcpy(FileNaine,FileEdit->Text.c_str  0  )  ; 

/***★★********************************★*****★**★**★★/ 

/*  READ  ALL  SATELLITES  FROM  THE  FILE,  AND  USE  THE  */ 

/*  FIRST  SATELLITE  IN  THE  FILE  AS  THE  TEST  CASE  */ 
/*******★★********★****★**★**★**********************/ 

ReadTLEF i 1 e ( F i 1 eName , 

*SatArray, 

*ErrorPtr) ; 

/***★****★*****★*******************************★★**★/ 

/*  NOTE  THE  Sat[0]  IS  THE  FIRST  SATELLITE  IN  THE  */ 

/*  FILE  */ 

/********★★*****★*****************★***********★*****/ 

SSCEdit->Text  =  String (SatArray->Sat [0 ]. GetSSCNumber ()) ; 

ClassEdit~>Text  =  String {SatArray->Sat [0] .GetSecurityClass ()) ; 
IntIDEdit->Text  =  String (SatArray->Sat [0] . GetInternationallD ( ) ) ; 
EpochYearEdit"->Text  =  String ( SatArray->Sat [ 0 ] . GetEpochYear ()); 
EpochDayEdit->Text  =  String (double (SatArray~>Sat [0] . GetEpochDay ( ) ) ) ; 
RevSquaredEdit->Text  =  String (double {SatArray->Sat [0] . GetRevSquared ( ) ) ) ; 
RevCubedEdit->Text  =  String (double (Sat Array->Sat [0] . GetRevCubed ( ) ) ) ; 
BStarEdit->Text  =  String (double (SatArray“>Sat [0] . GetBStarDrag ( ) ) ) ; 
EphemerisTypeEdit“>Text  =  String (SatArray->Sat [0] .GetEphemerisType ( ) ) ; 
ElSetEdit->Text  =  String (SatArray->Sat [0] . GetElementSetNumber ( ) ) ; 
InclinationEdit->Text  =  String (double (SatArray~>Sat [0] .Getinclination ( ) ) ) ; 
RightAscensionEdit->Text=String (double (Sat Array- 
>Sat[0] .GetRightAscension ( ) ) ) ; 

EccentricityEdit->Text  =  String (double ( SatArray- 
>Sat [ 0 ] . GetEccentricity ( ) ) ) ; 

ArgumentOf PerigeeEdit->Text  =  String (double (SatArray- 
>Sat[0] .GetArgumentOfPerigee ( ) )  )  ; 

MeanAnomalyEdit->Text  =  String (double (SatArray->Sat [0] .GetMeanAnomaly ( ) ) ) ; 
MeanMotionEdit->Text  =  String (double (SatArray->Sat [0] . GetMeanMotion ( ) ) ) ; 
RevNuinberEdit->Text  =  String (SatArray->Sat[0].GetRevAtEpoch()); 


/****★*★*★* **************************** ******* **★**★/ 

/*  DISPLAY  ALL  ERRORS  */ 

/********************************************i,-k-k-lc***/ 

CreateDisplayText (ErrorList,  Errors); 
if  (ErrorList .TotalErrors ()! =0) 

{ 

ErrorMemoBox->Lines->Clear() ; 

ErrorMeinoBox->Lines->Add ( "THERE  ARE  ERRORS..."); 
for  (i  =  0;  i<ErrorList .TotalErrors 0 ;  i++) 
ErrorMemoBox->Lines->Add (Errors [i] ) ; 

} 

else 

{  ErrorMeinoBox->Lines->Clear  ( )  ; 

ErrorMemoBox->Lines->Add( "No  Errors ..."); 

} 
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} 


/***********★****★:*:******★★*★***★*★*****************/ 

/*  THIS  PROCEDURE  ACTUALLY  RUNS  THE  TEST  CASE  AS  */ 

/*  IT  HAS  BEEN  ENTERED  INTO  THE  FORM  AND  DISPLAYS  */ 

/*  THE  RESULTS  OF  THE  RUN  */ 

/***********★★********★*★*****★***★*****************/ 

void _ fastcall  TForml : : RunButtonClick (TObject  *Sender) 

{ 

ErrorStructure  ErrorList; 

ErrorStructure  *ErrorPtr=&ErrorList ;  /*  A  POINTER  TO  ERRORLIST  */ 
Satellite*  Sat; 

Sat  =  new  Satellite; 

char  Errors [MAXERRORS] [MAXMESSAGELENGTH] ; 
int  i  ; 

char  buff  [MAXNAMELENGTH]  ; 
double  JulianDate; 
double  Inclination; 

double  *InclinationPtr  =  &Inclination; 
double  RightAscension; 

double  *RightAscensionPtr  =  &RightAscension; 
double  Eccentricity; 

double  *EccentricityPtr  =  ScEccentricity; 
double  MeanMotion; 

double  *MeanMotionPtr  =  ScMeanMotion; 
double  ArgumentOf Perigee; 

double  *ArgumentOfPerigeePtr  =  &ArgumentOf Perigee ; 
double  MeanAnomaly  ; 

double  *MeanAnomalyPtr  =  ScMeanAnomaly; 
double  X; 

double  *XPtr  =  &X; 
double  Y; 

double  *YPtr  =  &Y; 
double  Z; 

double  *ZPtr  =  &Z; 
double  Xdot; 

double  *XdotPtr  =  ScXdot; 
double  Ydot; 

double  *YdotPtr  =  ScYdot; 
double  Zdot; 

double  *ZdotPtr  =  &Zdot; 
double  Delta; 

double  *DeltaPtr  =  ScDelta; 


/*********★*******★*************************** ^ 

/*  GET  SATELLITE  EPHEMERIS  INFORMATION  */ 

/*****:f***************************************/ 

Sat->SetSSCNuiTiber  {SSCEdit->Text  ,ToInt  ( )  )  ; 
strcpy (buf f ,ClassEdit->Text .c_str () ) ; 
Sat->SetSecurityClass(buff) ; 
strcpy (buff , IntIDEdit->Text .c_str {) ) ; 
Sat-’>SetInternationalID(buf  f )  ; 

Sat->SetEpochYear (EpochYearEdit->Text.ToInt 0 ) ; 
Sat-‘>SetEpochDay{EpochDayEdit->Text.ToDouble( )  )  ; 
Sat“>SetRevSquared(RevSquaredEdit-->Text.ToDouble()  )  ; 
Sat“>SetRevCubed{RevCubedEdit->Text.ToDouble() ) ; 
Sat-'>SetBStarDrag(BStarEdit->Text.ToDouble()  )  ; 
Sat->SetEpheinerisType (EphemerisTypeEdit->Text .Toint 0 ) ; 
Sat~>SetElementSetNumber(ElSetEdit->Text.ToInt() ) ; 
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Sat->SetInclination ( InclinationEdit->Text .ToDouble ( ) ) ; 

Sat->SetRightAscension(RightAscensionEdit~>Text.ToDouble 0 ) ; 

Sat-'>SetEccentricity  (EccentricityEdit-’>Text  .ToDouble  ( )  )  ; 

Sat”>SetArgumentOf Perigee (ArgumentOf PerigeeEdit->Text . ToDouble ()); 

Sat“>SetMeanAnomaly (MeanAnomalyEdit->Text . ToDouble ()); 

Sat->SetMeanMotion{MeanMotionEdit->Text .ToDouble ( ) ) ; 

Sat“>SetRevAtEpoch (RevNuinberEdit->Text .Toint ( ) ) ; 

JulianDate  =  JulianDateEdit->Text .ToDouble () ; 

y'***************************************************/ 

/*  MAKE  A  CALL  TO  THE  SGP4  PROPAGATOR  */ 

/********★**★****★***********************★**★*******/ 

CallSGP4 (*Sat, 

JulianDate, 

*XPtr, 

*YPtr, 

*ZPtr, 

*XdotPtr, 

♦YdotPtr, 

*ZdotPtr, 

*InclinationPtr , 

*RightAscensionPtr , 

*EccentricityPtr , 

*MeanMot ionPtr , 

* ArgumentOf Per igeePtr , 

*MeanAnomalyPtr , 

*DeltaPtr, 

*ErrorPtr) ; 

/**★************★************** ***★**★********/ 

/*  Convert  Mean  Motion  from  radians /sec  to  */ 

/*  revolutions  per  day  */ 

/*********************************************/ 

MeanMotion  =  MeanMotion  *  MINUTESPERDAY  /  TWOPI; 

/**********★★********★*★*****★**★*****★*★***********/ 

/*  DISPLAY  THE  RESULTS  OBTAINED  FROM  SGP4  */ 

/********★**************★*★***★************★*****★**/ 

XEdit->Text  =  String (X); 

YEdit->Text  =  String (Y); 

ZEdit~>Text  =  String (Z) ; 

XdotEdit->Text  =  String (Xdot) ; 

YdotEdit”>Text  =  String (Ydot) ; 

ZdotEdit->Text  =  String (Zdot) ; 

DeltaEdit”>Text  =  String (Delta) ; 

InclinOutEdit->Text  =  String ( Inclination) ; 

RightAsOutEdit->Text  =  String (RightAscension) ; 

EccentricityOutEdit->Text  =  String(Eccentricity); 

MeanMotionOutEdit->Text  =  String (MeanMotion) ; 

ArgOfPerigeeOutEdit“>Text  =  String (ArgumentOf Perigee ) ; 

MeanAnomalyOutEdit“>Text  =  String (MeanAnomaly) ; 

DeltaEdit“>Text  =  String (Delta); 


/**★★**★**★*****************★**★**★******★**********/ 

/*  DISPLAY  ALL  ERRORS  */ 

/★★★★★★★■A-*******************************************/ 

CreateDisplayText (ErrorList ,  Errors) ; 
if  (ErrorList .TotalErrors ( ) ! =0) 

{ 

ErrorMemoBox->LineS’->Clear  ( )  ; 

ErrorMemoBox-'>Lines->Add(  "THERE  ARE  ERRORS..."); 
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for  (i  =  0;  i<ErrorList . TotalErrors ( ) ;  i++) 
ErrorMemoBox->Lines->Add {Errors [i] ) ; 


} 

else 

{  ErrorMemoBox->Lines->Clear 0 ; 

ErrorMemoBox->Lines->Add ( "No  Errors 

} 

} 

j  f - 

A.6  Error  Handling 

Each  of  the  event-handlers  in  the  code  listed  above  can  be  seen  to  have  an  error 
handling  routine  that  lists  out  all  errors  that  have  been  trapped  by  the  program.  It  is 
important  that  the  structure  of  this  error-handling  be  known  for  any  programmers  in  the 
future  who  may  wish  to  adopt  all  or  part  of  the  coded  modules  of  this  project.  Each 
module  within  both  the  ABLPA  Preprocessor  and  the  ABLPA  Main  Processor  have  an 
extra  parameter  in  their  parameter  list  that  holds  and  traps  any  errors  handled  by  the 
program.  This  error  parameter  is  always  the  last  parameter  on  the  visible  parameter  list 
and  can  only  be  accessed  by  the  manipulation  routines  held  in  the  module 
“ErrorStructure”.  These  routines  and  the  nature  of  the  error-handling  system  are 
discussed  in  greater  detail  further  in  this  paper. 
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Appendix  B.  ABLPA  Preprocessor  Software  Implementation 


The  Airborne  Laser  Predictive  Avoidance  (ABL-PA)  Preprocessor  is  only  a  part 
of  the  software  developed  in  this  project.  Figure  B.l  illustrates  how  this  preprocessor  fits 
into  the  overall  hierarchy  of  the  software. 


Figure  B.l  Where  the  ABLPA  Preprocessor  Fits  in  the  Software 

Hierarchy 

It  can  be  seen  that  the  task  of  the  preprocessor  is  to  take  the  input  file  containing  all 
active  satellites  in  orbit,  and  strip  out  only  those  satellites  that  are  in  view  of  the  laser 
platform  at  a  given  time.  The  preprocessor  then  creates  an  output  file  containing  the 
satellites  in  view.  This  output  file  has  exactly  the  same  format  as  the  main  TLE  file, 
except  it  has  fewer  satellites  within  it. 
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B.l  Preprocessor  Modular  Format 

The  preprocessor  is  a  conglomeration  of  many  software  libraries  that  were  created 
and  tested  independently  before  being  combined  to  form  the  preprocessor.  Figure  B.2 
shows  the  basic  libraries  that  comprise  the  preprocessor,  and  the  modules  each  library 
contains.  Each  library  and  module  shown  will  be  explained  within  this  chapter. 


ABLPAPreprocessorF  orm.  cpp 
(CBuilder  Graphical  Interface) 

_ S _ 

PAPreprocessor.  cpp 
(Main  C++  Routine) 


TLEInput.cpp 


T  imeModules.  cpp 


EvaluateEphemeri^odules.cpp 


Convert 
Calendar 
To  Julian 


Convert 
Julian  To 
Calendar 


Read  TLE 
File 


1/ 


ErrorStructure.  cpp 
Laser  Con  stants.h 


Satellite.  q)p 


Aircraft.  q)p 


(Core  Modules  - 
Called  by  All) 


Figure  B.2  ABLPA  Preprocessor  Calling  Tree 

From  Figure  B.2  it  can  be  seen  that  modules  could  be  roughly  grouped  into  six  libraries. 
Each  of  these  is  listed  in  Table  B.l.  Each  of  these  libraries  of  modules  has  been  designed 
to  be  a  project  in  and  of  themselves,  tested  using  their  own  GUI  as  seen  in  the  table. 
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Table  B.1  The  Six  Libraries  Composing  the  ABLPA  Preprocessor 


Software 
Library  Title 

Modules  Tested 
(C++) 

GUI  Interface 
Module 

(C++  Builder  3) 

Purpose 

ABLPA 

Preprocessor 

All  preprocessor  modules 
as  shown  in  Figure  B.2 

PAPreprocessorForm 

To  provide  a  user- 
friendly  way  to  run 
the  preprocessor 

Test  Error 
Structure 

ErrorStructure.cpp 
CreateDisplayT  ext 
AddError 
GrabError 

TestErrorStructure 
Text  Only  - 
Non-(Graphical) 

To  test  the  error 
handling  routines 
used  to  record  and 
store  errors 

SGP4  Support 

CallSGP4 

SGP4Routines 

Core  Modules 

SGP4TestForm 

To  test  the  interface 
with  SGP4,  as  well 
as  the  output 
received  from  the 
propagator 

Time  Module 
Test 

ConvertJulieinToCalendar 
ConvertCalendarT  oJulian 
Core  Modules  ' 

TimeTestForm 

To  test  the  time 
conversion  modules 

TLE  Input  Test 

ReadTLEFile 

Core  Modules 

TLETestForm 

To  test  the  module, 
that  reads  the  Two- . 
Line  Element  Set 
files  used  by  the 
software 

Test  Evaluate 
Ephemeris 

EvaluateEphemeris 

CompareOrbit 

FindThetaG 

Core  Modules 

EvaluateEphemerisForm 

To  test  the 
evaluation  of  a 
single  satellite 

The  discussion  of  the  preprocessor  will  progress  through  each  of  these  libraries 
individually,  discussing  the  nature  of  the  function  served  by  the  library,  as  well  as 
comments  on  each  module  within  that  library.  The  interfaces  and  input/output 
parameters  used  with  each  module  will  be  emphasized.  The  actual  code  for  each  module 
in  the  ABLPA  Preprocessor  will  be  listed  out  in  Appendix  D.  The  code  for  each  sub- 
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project  GUI  interface  will  be  listed  in  Appendix  E.  Only  the  “Header  File”  or  the  files 
with  the  “.h”  extension  will  be  listed  here  in  the  discussion,  because  they  are  short  and 
contain  important  interface  information  that  should  be  discussed.  All  of  the 
implementation  code  will  be  included  in  their  respective  Appendices. 


B.2  The  Core  Modules 

The  Core  Modules  are  modules  that  are  used  extensively  throughout  bot  the 
Preprocessor  and  the  Main  Processor.  They  consist  of  the  modules,  Aircraft.cpp, 
Satellite.cpp,  LaserConstants.h,  and  ErrorStructure.cpp.  Except  for  ErrorStructure.cpp, 
none  of  the  Core  Modules  are  tested  exclusively,  because  their  design  is  fairly  simple, 
and  their  function  is  easily  recognized. 


B.2.1  Aircraft.h 

This  module  defines  the  “Aircraft”  object.  This  object,  or  data-type,  is  used  to 
store  all  information  needed  about  the  aircraft  platform  parameters,  including  position, 
speed,  and  etc.  Its  header  file,  which  follows,  describes  the  various  manipulation 
functions  defined  to  work  with  the  Aircraft  object.  If  more  clarification  is  required,  the 
implementation  listing  in  Appendix  D  may  help  to  clarify. 

/**★**★*★*★* ********************************** **★***★***★********************/ 


/* 

MODULE  NAME: 

Aircraft.h 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

Sept  19,  1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  module  of  code  houses  the  Aircraft  class  object. 

*/ 

/* 

*/ 

/* 

COMPILER: 

Borland  C++  Builders  Standard  version 

*/ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 
/**********★**★********★*************★************★★*********★★**************/ 

#ifndef  AircraftH 
#define  AircraftH 

#include  "LaserConstants.h” 
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class  Aircraft  { 
public : 

Aircraft ( ) ; 
-Aircraft ( )  ; 


/****★*★*★★*★**********★*************★**/ 
/*  AIRCRAFT  MANIPULATION  FUNCTIONS  */ 
/***************************************/ 


void  SetLatitudeDegree (int  Id) ; 
void  SetLatitudeMinute (int  Id) ; 
void  SetLatitudeSecond( double  Is) ; 
void  SetLatitudeHemi sphere (int  h) ; 
void  SetLongitudeDegree (int  Id) ; 
void  SetLongitudeMinute (int  Id) ; 
void  SetLongitudeSecond (double  Is) ; 
void  SetVelocityX (double  vel) ; 
void  SetVelocityY (double  vel); 
void  SetVelocityZ (double  vel) ; 
void  SetAltitude (double  alt) ; 


int 

int 

double 

int 

int 

int 

double 

double 

double 

double 

double 


GetLatitudeDegree ( ) ; 
GetLatitudeMinute ( ) ; 
GetLatitudeSecond ( ) ; 
GetLatitudeHemi sphere ( ) ; 
GetLongitudeDegree ( )  ; 
GetLongitudeMinute ( ) ; 
GetLongitudeSecond ( ) ; 
GetVelocityX ( ) ; 
GetVelocityY ( ) ; 
GetVelocityZ ( ) ; 

Get Altitude ( ) ; 


private  : 
int 
int 

double 

int 

int 

int 

double 

int 

int 

int 

double 


LatitudeDegree ; 

Lat i tudeMinute ; 
LatitudeSecond; 

La t i tudeHemi sphere ; 
Longi tudeDegree  ; 
Longi tudeMinute ; 
Longi tudeSecond; 
VelocityX; 
VelocityY; 
VelocityZ; 

Altitude; 


}; 


#endif 
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B.2.2  SatelUte.h 


This  module  defines  the  “Satellite”  object.  This  object,  or  data-type,  is  used  to 
store  all  information  needed  about  the  satellite  ephemeris  parameters.  Its  header  file, 
which  follows,  describes  the  various  manipulation  functions  defined  to  work  with  the 


Satellite  object.  If  more  clarification  is  required,  the  implementation  listing  in  Appendix 
D  may  help  to  clarify. 


/*  MODULE  NAME:  Satellite. h  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  July  25,  1998  */ 
/*  */ 
/*  PURPOSE:  This  module  of  code  houses  the  Satellite  class  object.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/***★******★*★******★********★*****************************************.*.*****  ^ 

#ifndef  SatelliteH 
tdefine  SatelliteH 

tinclude  "LaserConstants .h" 


class  Satellite  { 
public : 

Satellite { ) ; 
--Satellite  { )  ; 


/********★**********★****★****************************** ^ 
/*  SATELLITE  MANIPULATION  FUNCTIONS.  MANY  OF  THESE  */ 
/*  FUNCTIONS  ARE  BASED  ON  THE  FIELDS  OF  THE  TWO-LINE  */ 
/*  ELEMENT  SET  INPUT  FORMAT  USED  BY  SPACE  COMMAND.  */ 


void  SetName(char  name [MAXINPUTLINELENGTH] ) ; 
void  SetSSCNumber (long  int  ssc) ; 
void  SetRevAtEpoch (long  int  rev) ; 

void  SetSecurityClass (char  s ec class [CLASSLENGTH+1] ) 

void  SetInternationalID(char  intID [INTNUMLENGTH+1] ) 

void  SetEpochYear ( int  eyear) ; 

void  SetEphemerisType (int  etype) ; 

void  SetElementSetNumber ( int  esetnum) ; 

void  SetEpochDay (long  double  eday) ; 

void  SetRevSquared (long  double  rev2); 

void  SetRevCubed (long  double  rev3); 

void  SetBStarDrag ( long  double  bstar) ; 

void  SetSemiMajorAxis (long  double  sma) ; 

void  SetEccentricity (long  double  e) ; 

void  SetRightAscension (long  double  ra) ; 

void  Setinclination (long  double  i) ; 

void  SetArgumentOf Perigee (long  double  ap) ; 

void  SetMeanAnomaly (long  double  ma) ; 
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void  SetEccentricAnomaly ( long  double  ea) ; 
void  SetTrueAnomaly (long  double  ta) ; 
void  SetScalarRadius (long  double  sr) ; 
void  SetMeanMot ion (long  double  mm) ; 

void  Satellite: zSetTLELinel (char  line [MAXINPUTLINELENGTH] ) 
void  Satellite: :SetTLELine2 (char  line [MAXINPUTLINELENGTH] ) 

char*  GetNameO; 

long  int  GetSSCNumber ( ) ; 
long  int  GetRevAtEpoch ( ) ; 
char*  GetSecurityClass ( ) ; 

char*  GetInternationallD ( ) ; 

int  GetEpochYear ( ) ; 

int  GetEphemerisType ( ) ; 

int  GetElementSetNumber ( ) ; 

long  double  GetEpochDay ( ) ; 
long  double  GetRevSquared ( ) ; 
long  double  GetRevCubed ( ) ; 
long  double  GetBStarDrag ( ) ; 
long  double  GetSemiMajorAxis ( ) ; 
long  double  GetEccentricity ( ) ; 
long  double  GetRightAscension( ) ; 
long  double  Getinclination ( ) ; 
long  double  GetArgumentOf Perigee ( ) ; 
long  double  GetMeanAnomaly ( ) ; 
long  double  GetEccentricAnomaly ( ) ; 
long  double  GetTrueAnomaly ( ) ; 
long  double  GetScalarRadius ( ) ; 
long  double  GetMeanMotion ( ) ; 
char*  Satellite: :GetTLELinel() ; 
char*  Satellite: :GetTLELine2 () ; 

private  : 

long  double  SemiMajorAxis ; 
long  double  Eccentricity; 
long  double  RightAscension; 
long  double  Inclination; 
long  double  ArgumentOf Perigee ; 
long  double  MeanAnomaly; 
long  double  EccentricAnomaly; 
long  double  TrueAnomaly; 
long  double  ScalarRadius ; 
char  Name  [MAXNAMELENGTH]  ; 

long  int  SSCNumber; 
long  int  RevAtEpoch; 

char  SecurityClass [CLASSLENGTH+1] ; 

char  InternationalID[INTNUM[LENGTH+l]  ; 

int  EpochYear; 

int  EphemerisType; 

int  ElementSetNumber ; 

long  double  EpochDay; 

long  double  RevSquared; 

long  double  RevCubed; 

long  double  BStarDrag; 

long  double  MeanMotion; 

char  TLELinel [MAXINPUTLINELENGTH] ; 

char  TLELine2 [MAXINPUTLINELENGTH] ; 

}; 

/******★★****************★*************★******/ 

/*  THIS  STRUCTURE  HOLDS  AN  ARRAY  OF  SATS  */ 

/★★★*****★*★** ********************************/ 
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struct  SatStructure  { 

Satellite  Sat [MAXSATELLITES] ; 
int  NumSats; 

}; 


#endif 


B.2.3  LaserConstants.h 


LaserConstants.h  is  the  header  file  where  all  of  the  physical  constants  for  the 


Preprocessor  and  the  Main  Processor  are  defined.  The  header  file  follows. 


/*********★****** 

************************************************************/ 

/* 

MODULE  NAME: 

LaserConstants . h 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

July  21 ,  1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  module  houses  some  of  the  basic  constants  used  in 

*/ 

/* 

the  deconfliction  of  a  laser  beam  with  the  path  of  a 

*/ 

/* 

satellite . 

*/ 

/* 

*/ 

/* 

COMPILER: 

Borland  C++  Builder3  Standard  version 

*/ 

/* 

This  compiler  should  be  used  to  compile  and  link. 

*/ 

/* 

*/ 

#ifndef  LaserConstantsH 
#define  LaserConstantsH 

/****★****************★***  CONSTANT  DEFINITIONS  ********************★**/ 


#def ine 

MAXNAMELENGTH 

50 

/* 

#def ine 

GRAVITYCONSTANT 

398601000 

/* 

#def ine 

MAXMESSAGELENGTH 

300 

/* 

#def ine 

MAXERRORS 

50 

/* 

# define 

MAXSATELLITES 

1000 

/* 

#def ine 

NOERRORS 

0 

/* 

#def ine 

ERRORFOUND 

1 

/* 

#def ine 

MAXINPUTLINELENGTH  70 

/* 

#def ine 

EARTHRADIUS 

6378.135 

/* 

# define 

MUEARTH 

398601 

/* 

#def ine 

PI  3 

.14159265358979/* 

#def ine 

TWOPI  6 . 

283185307179586/* 

#def ine 

DEGTORADIANS 

0.01745329252 

/* 

#def ine 

RADTODEGREES 

57.2957795131 

/* 

# define 

MINUTESPERDAY 

1440 

/* 

#def ine 

SECS S I DEREALDAY 

86164.09054 

/* 

#def ine 

SECSPER24HOURS 

86400 

/* 

#def ine 

SECSPERHOUR 

3600 

/* 

#define 

LATEREFERENCE 

31536000 

/* 

/* 

/* 

/* 

/* 

#def ine 

MMREVSPERDAY 

8681660.4 

/* 

/* 

EACH  NAME  CAN  BE  ONLY  50  CHARS  MAX  */ 
m/sec  */ 
MAXIMUM  LENGTH  OF  AN  ERROR  MESSAGE  */ 
MAX  NUMBER  OF  ERROR  MESSAGES  */ 
MAX  SATELLITES  THAT  CAN  BE  READ  */ 
BOOLEAN  ERROR  FLAG  */ 
BOOLEAN  ERROR  FLAG  */ 
MAXIMUM  CHARS  OF  LINE  IN  INPUT  FILE*/ 
EARTH  RADIUS  IN  KILOMETERS  */ 
GRAV  CONSTANT  IN  km3/sec2  */ 
OBVIOUS  * / 
OBVIOUS  * / 
DEGREE  TO  RADIAN  CONVERSION  FACTOR  */ 
RADIAN  TO  DEGREE  CONVERSION  FACTOR  */ 
DAYS  TO  MINUTES  CONVERSIONS  FACTOR  */ 

#  OF  SECONDS  IN  A  SIDEREAL  DAY  */ 

#  OF  SECONDS  IN  24  HOURS  */ 

#  OF  SECONDS  IN  AN  HOUR  */ 
TIME  IN  SECONDS  BY  WHICH  THETA  G  */ 
CAN  BE  SAFELY  PROPAGATED.  NOTE:  */ 
31536000  =  365*24*3600  (1  YEAR  IN  */ 

SECONDS)  */ 
THIS  IS  USED  TO  EXTRACT  THE  SEMI  */ 
MAJOR  AXIS  FROM  THE  MEAN  MOTION  */ 
REVOLUTIONS  PER  DAY.  IE:  */ 
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/*  MM  =  8681660.4  *  a^{-3/2)  */ 

/*■*•★*★****■****★*•*•★***★★**********★*********★★*•★****★****★*★****★/ 

/*  THE  FOLLOWING  CONSTANTS  DEFINE  BOTH  THE  STARTING  POSITIONS  */ 

/*  OF  EACH  OF  THE  INPUT  FIELDS  IN  THE  TWO  LINE  ELEMENT  */ 

/*  (or  TLE)  INPUT  FILE  AND  THE  LENGTH  OF  THOSE  FIELDS.  THEY  */ 

/*  ARE  EXPRESSED  IN  TERMS  OF  CHARACTER  POSITION  FROM  THE  */ 

/*  BEGINNING  OF  THE  LINE  (POS) ,  AND  LENGTH  OF  FIELD  (LENGTH).  */ 

/*  THE  LENGTH  IS  ALSO  IN  CHARACTERS  OF  THE  FIELD  (NOT  DIGITS) .*/ 

^*ir**-k**********-k*ifk-kir*******-k***-k-k-k****'k*-k****-k-ic*iric******it*****^ 


#def ine 

CARDPOS 

1 

/* 

CARD  NUMBER 

*/ 

#def ine 

CARDLENGTH 

1 

# define 

SSCPOS 

3 

/* 

SSC  NUMBER 

*/ 

#def ine 

SSCLENGTH 

5 

# define 

CLASSPOS 

8 

/* 

SECURITY  CLASSIFICATION 

*/ 

#define 

CLASSLENGTH 

1 

# define 

INTNUMPOS 

10 

/* 

INTERNATIONAL  NUMBER 

*/ 

#define 

INTNUMLENGTH 

8 

#def ine 

EYEARPOS 

19 

/* 

EPOCH  YEAR 

*/ 

#def ine 

EYEARLENGTH 

2 

#def ine 

EDAYPOS 

21 

/* 

EPOCH  DAY 

*/ 

# define 

EDAYLENGTH 

12 

#def ine 

REV2POS 

34 

/* 

REVOLUTIONS  PER  DAY  SQUARED 

*/ 

#def ine 

REV2 LENGTH 

10 

#def ine 

REV3POS 

45 

/* 

REVOLUTIONS  PER  DAY  CUBED 

*/ 

# define 

REV3 LENGTH 

6 

#def ine 

REVPOWERPOS 

51 

/* 

REVOLUTIONS  PER  DAY  CUBED 

*/ 

# define 

REVPOWERLENGTH 

2 

#def ine 

BSTARPOS 

54 

/* 

BSTAR  DRAG 

*/ 

#def ine 

BSTARLENGTH 

6 

#def ine 

BPOWERPOS 

60 

/* 

BSTAR  DRAG 

*/ 

#def ine 

BPOWERLENGTH 

2 

#def ine 

ETYPEPOS 

63 

/* 

EPHEMERIS  TYPE 

*/ 

#def ine 

ETYPELENGTH 

1 

#def ine 

ELSETPOS 

65 

/* 

ELEMENT  SET  NUMBER 

*/ 

#def ine 

ELSETLENGTH 

4 

#def ine 

INCLINPOS 

9 

/* 

INCLINATION 

*/ 

#def ine 

INCLINLENGTH 

8 

#def ine 

RIGHTASPOS 

18 

/* 

RIGHT  ASCENSION 

*/ 

#def ine 

RIGHTASLENGTH 

8 

#def ine 

ECCPOS 

27 

/* 

ECCENTRICITY 

*/ 

#def ine 

ECCLENGTH 

7 

# define 

ARGPERPOS 

35 

/* 

ARGUMENT  OF  PERIGEE 

*/ 

#def ine 

ARGPERLENGTH 

8 

#def ine 

MEANANPOS 

44 

/* 

MEAN  ANOMALY 

*/ 

#def ine 

MEANANLENGTH 

8 

#def ine 

MEANMOPOS 

53 

/* 

MEAN  MOTION  (Revolutions  per  day) 

*/ 

#def ine 

MEANMOLENGTH 

11 

#def ine 

EPOCHREVPQS 

64 

/* 

REVOLUTION  NUMBER  AT  EPOCH 

*/ 

#def ine 

EPOCHREVLENGTH 

5 

#endif 
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B.3  The  Error  Structure  Project 


This  portion  of  the  preprocessor  deals  with  the  handling,  recording,  and 
displaying  of  errors  within  the  software.  The  error  handling  modules  are  used  throughout 
both  the  Preprocessor  and  the  Main  Processor.  The  three  modules  that  are  used  for  error 
handling  are  all  held  in  ErrorStructure.cpp.  These  three  modules  are  CreateDisplayText, 
AddError,  and  GrabError.  ErrorStructure.cpp  also  defines  the  ErrorStructure  object, 
that  is  used  to  store  all  errors  recorded.  The  Test  Error  Project  has  only  a  text-driven  user 
interface  that  can  be  run  in  the  DOS  environment. 


B.3.1  AddError 

This  module  will  add  an  error  to  the  ErrorStructure,  given  information  about  the 
error  being  recorded.  It  receives  this  information  via  three  input  parameters  described 
below. 

Inputs 


char  moduleName  [MAXNAMELENGTH]  The  Text  name  of  the  software 
module  in  which  the  error  occurred.  MAXNAMELENGTH  is  defined  in 
LaserConstants.h. 

char  description  [HAXMESSA6ELEN6TH]  A  text  description  of  the 
error.  MAXMESSAGELENGTH  is  defined  in  LaserConstants.h. 


int  severity  The  severity  of  the  error: 

0  =  Warning  only 

1  =  Critical  Error  (An  error  terminal  to  the  program) 

AddError  gives  no  tangible  outputs,  but  loads  the  information  into  the  ErrorStructure. 
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B.3.2  GrabError 


\ 

\ 


GrabError  grabs  an  error  from  the  ErrorStructure.  As  inputs,  GrabError  requires 
only  the  number  of  the  error  to  be  retrieved. 

Inputs 


int  number  This  is  the  only  input  GrabError  requires.  It  is  the  number 
(between  1  and  MAXERRORS)  of  the  error  to  be  fetched. 

Outputs 

char  moduleName  [MAXNAMELENGTH]  The  module  where  the  error  being 
fetched  occurred. 

char  description  [MAXMESSAGELENGTH]  The  description  of  the  error 
being  fetched. 

int  fiseverity  The  severity  of  the  error: 

0  =  Warning  only 

1  =  Critical  Error  (An  error  terminal  to  the  program) 

int  &f  ound  A  boolean  flag  telling  whether  the  error  asked  for  was  found; 

0  =  Not  found 
1 =  Found 


B.3.3  CreateDispIayText 

There  was  a  need  to  convert  the  errors  from  the  ErrorStructure  format  to  straight 
text,  so  that  the  errors  could  be  accessed  by  outside  interfaces  that  only  recognize  C- 
Strings.  This  module  converts  the  list  of  errors  in  the  ErrorStructure  to  an  ordinary  array 
of  type  char. 

Inputs 


ErrorStructure  &errors  This  would  be  the  variable  of  t5q)e 
ErrorStructure  that  holds  the  errors  to  be  converted. 
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Outputs 


char  text  [MAXERRORS]  [MAXMESSA6ELENGTH]  This  is  a  two- 

dimensional  array  or  characters  that  holds  a  one-line  combined  description  of 
each  error  in  the  ErrorStructure. 


The  header  file  describing  AddError,  GrabError,  and  CreateDisplayText,  and  the  rest  of 
the  ErrorStructure  library,  follows.  Notice  the  modules  CriticalError  and  WamingError 
are  used  to  assess  whether  any  errors  of  those  respective  types  have  occurred. 


B.3.4  The  ErrorStructure.h  Header  File 


/*  MODULE  NAME:  ErrorStructure.h  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  July  25,  1998  */ 
/*  */ 
/*  PURPOSE:  This  module  of  code  houses  the  error  structure  which  */ 
/*  will  be  used  to  hold  and  trap  any  error  conditions  that  */ 
/*  arise  during  the  operation  of  the  program.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  Builder!  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/****************************************************************************/ 

iifndef  ErrorStructureH 
#define  ErrorStructureH 

# include  "LaserConstants . h" 


class  ErrorStructure  { 
public : 

ErrorStructure ( ) ;  / *  CONSTRUCTOR  * / 

-ErrorStructure ( ) ;  / *  DESTRUCTOR  * / 


/*  ErrorStructure  MANIPULATION  FUNCTIONS  * 


/*  FUNCTION  NAME:  AddError  * 
/*  AUTHOR:  Captain  David  Vloedman  * 
/*  DATE  CREATED:  July  25,  1998  * 
/* 


/*  PURPOSE:  This  function  is  used  to  record  an  error  into  the  error  * 
/*  structure.  * 
/**************************************************************************** 


/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


void  AddError ( char 
char 
int 


moduleName  [MAXNAMELENGTH]  , 
description [MAXMESSAGELENGTH] , 
severity) ; 
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/* 

FUNCTION  NAME; 

GrabError 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

July  25,  1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  function  is  used  to  retrieve  an  error 

that  has  been*/ 

/* 

previously  added  to  the  error  structure. 

*/ 

void  GrabError ( int 
char 
char 
int 
int 


number , 

moduleName[MAXNAMELENGTH]  , 
description [MAXMESSAGELENGTH] , 
ficseverity, 

& found) ; 


/* 

FUNCTION  NAME; 

CriticalError 

*/ 

/* 

AUTHOR; 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

July  25,  1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  function  is  used  to  determine  if  a  critical 

(fatal) */ 

/* 

error  has  been  detected  and  recorded  yet. 

*/ 

/* 

CriticalErrorFound  :=  1  — >  TRUE 

*/ 

/* 

CriticalErrorFound  =0  — >  FALSE 

*/ 

/*  */ 
int  CriticalError ( ) ; 


/*  FUNCTION  NAME;  WarningError  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED;  July  25,  1998  */ 
/*  */ 
/*  PURPOSE:  This  function  is  used  to  determine  if  a  warning  (non-  */ 
/*  fatal)  error  has  been  detected  and  recorded  yet.  */ 
/*  WarningFound  =  1  -->  TRUE  */ 
/*  WarningFound  =  0  FALSE  */ 
/*  */ 


int  WarningError ( ) ; 


/*  FUNCTION  NAME;  TotalErrors  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  July  25, 1998  */ 
/*  */ 
/*  PURPOSE;  This  function  is  used  to  determine  how  many  errors  total*/ 
/*  have  occurred  and  been  recorded.  */ 
/*  ErrorsFound  =  Total  number  of  errors.  */ 
/*  */ 


int  TotalErrors ( )  ; 


/**★**★**★★****★*********************★*******/ 
/*  These  private  structures  cannot  be  seen  */ 
/*  outside  this  module.  They  are  used  to  */ 
/*  errors  and  are  interfaced  with  by  the  */ 
/*  public  functions.  */ 
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/*****★****************************★**★*****★/ 
private  : 

int  CriticalErrorFound; 
int  WarningFound ; 
int  ErrorsFound; 

char  ModuleList[MAXERRORS] [MAXNAMELENGTH] ; 
char  ErrorList [MAXERRORS] [MAXMESSAGELENGTH] ; 
int  Severity [MAXERRORS] ; 

}; 


FUNCTION  NAME: 
AUTHOR : 

DATE  CREATED: 


CreateDisplayText 
Captain  David  Vloedman 
July  25,  1998 


PURPOSE : 


This  function  is  used  to  create  a  simple  array  of  */ 
character  arrays  which  hold  all  of  the  information  */ 
held  in  the  error-structure.  This  two-dimensional  */ 
text  array  may  have  messages  as  long  as  MAXMESSAGELENGTH*/ 
and  can  hold  MAXERRORS  messages.  */ 


PURPOSE : 

DataStructure  holding  all  errors 


OUTPUTS : 


NAME: 

text 


PURPOSE : 

A  completely  textual  version  of 


/*  errors.  */ 
/***★**★*****★★ ***★*****★*★**★*★★★* ****** ********★***************************/ 
void  CreateDisplayText {ErrorStructute  terrors, 

char  text [MAXERRORS] [MAXMESSAGELENGTH] ) ; 


#endif 
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B.4  The  SGP4  Support  Library 


The  SGP4  Support  Library  consists  of  all  of  the  modules  used  to  store  and 
interface  with  the  SGP4  satellite  ephemeris  propagator.  Although  SGP4  was  written 
independently  of  this  project  by  Air  Force  Space  Command,  a  copy  of  it  (version  3.01C) 
is  stored  in  the  module  SGP4Routines.cpp.  These  external  routines  are  accessed  using 
the  module  “CallSGP4”,  stored  in  the  SGP4SupportModules  library.  CallSGP4,  and 
consequently  SGP4  itself,  can  be  tested  using  the  Graphical  User  Interface  illustrated  in 
Figure  B.3.  The  GUI  below  is  controlled  by  the  Cbuilder  module  SGP4TestForm,  which 
was  developed  to  facilitate  testing  of  the  nature  and  behavior  of  the  interface  to  SGP4. 


Figure  B.3.  Testing  GUI  Used  to  Access  CallSGP4 


no 


B.4.1  CalISGP4 


As  mentioned  previously,  CallSGP4  is  the  module  used  to  call  and  interface  with 
SGP4.  The  input  and  output  interface  used  by  SGP4  is  proprietary  to  the  Air  Force,  and 
will  not  be  discussed  here,  however  the  interface  to  CallSGP4  can  be  explained. 

Inputs 


struct  Satellite  &Sat  This  first  input  is  just  the  Satellite  object 
that  holds  all  of  the  ephemeris  information  gleaned  from  a  Two-Line 
Element  Set  file,  and  populated  using  the  ReadTLEFile  module. 

double  JuliauDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 


Outputs 

double  &X  The  X  coordinate  of  the  satellite  at  the  Julian  Date  specified, 
given  in  terms  of  the  ECI  frame,  in  kilometers. 

double  &Y  The  Y  coordinate  of  the  satellite  at  the  Julian  Date  specified, 
given  in  terms  of  the  ECI  frame,  in  kilometers. 

double  &Z  The  X  coordinate  of  the  satellite  at  the  Julian  Date  specified, 
given  in  terms  of  the  ECI  frame,  in  kilometers. 

double  &Xdot  The  velocity  in  the  X  direction  (ECI  frame)  of  the  satellite  at 
the  Julian  Date  specified,  in  kilometers  per  second. 

double  &Ydot  The  velocity  in  the  Y  direction  (ECI  frame)  of  the  satellite  at 
the  Julian  Date  specified,  in  kilometers  per  second. 

double  &Zdot  The  velocity  in  the  Z  direction  (ECI  frame)  of  the  satellite  at 
the  Julian  Date  specified,  in  kilometers  per  second. 

double  &Inclination  The  inclination  of  the  satellite  at  the  Julian  Date 
specified,  in  degrees. 

double  &RightAscension  The  Right  Ascension  of  the  satellite  at  the 
Julian  Date  specified,  in  degrees. 


Ill 


double  &Eccentricity  The  Eccentricity  of  the  satellite  at  the  Julian  Date 
specified,  in  degrees. 

double  AMeaziMotion  The  Mean  Motion  of  the  satellite  at  the  Julian  Date 
specified. 

double  &Argu]nentO£Perigee  The  Argument  of  Perigee  of  the  satellite 
at  the  Julian  Date  specified,  in  degrees. 

double  &MeanAnoinaly  The  Mean  Anomaly  of  the  satellite  at  the  Julian 
Date  specified,  in  degrees. 

double  &Delta  This  is  the  time  that  has  elapsed  between  the  time  that  the 
original  ephemeris  data  for  the  satellite  (held  in  the  Satellite  object)  and  the  Julian 
propagation  date  specified.  In  other  words,  the  amount  of  time  (in  minutes)  that 
has  been  propagated. 

ErrorStructure  &ErrorList  The  error  handling  object. 


B.4.2  The  SGP4SupportModules.h  Header  File 


/*  MODULE  NAME:  SGP4SupportModules . h  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  October  20,  1998  */ 
/*  */ 
/*  PURPOSE:  This  set  of  modules  supports  incorporating  "SGP4",  a  */ 
/*  Satellite  position/ time  propagator  developed  by  */ 
/*  United  States  Space  Command.  These  modules  were  */ 
/*  developed  for  SGP4  Version  3.01C.  They  simply  serve  as  */ 
/*  an  interface  between  this  project  and  SGP4 .  */ 
/*  */ 
/*  COMPILER:  Borland  C++  Builder3  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


#ifndef  SGP4SupportModulesH 
idefine  SGP4SupportModulesH 

# include  "ErrorStructure.h" 

^***********************  FUCTIONS  *******************‘*-*********  j 


/*  FUNCTION  NAME:  CallSGP4  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  October  20,  1998  */ 
/*  */ 
/*  PURPOSE:  This  procedure  will  take  elements  already  existing  */ 
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/* 

/* 

/* 

/* 

/* 

/ *  INPUTS : 

/* 

/* 

/* 

/* 

/ *  OUTPUTS : 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/*  COMPILER: 
/* 

/* 


within  the  Predictive  Avoidance  Project  code  and  adapt 
that  information  slightly  to  be  used  by  SGP4  version 
3.01.  It  will  then  make  a  call  to  SGP4  and  return  the 
results . 


NAME: 

Sat 

JulianDate 

NAME: 

X 


Xdot 

Ydot 

Zdot 

Inclination 
RightAscension 
Eccentricity 
ArgumentOf Perigee 
Mean  Anomaly 
Delta 


ErrorList 


DEFINITION: 

Holds  all  ephemeris  information 
for  the  Satellite  being  studied 
The  time  to  which  the  position 
of  sat  should  be  propagated  to 
DESCRIPTION: 

X  axis  pos  in  ECI  frame  at  Jul 
date 

Y  axis  pos  in  ECI  frame  at  Jul 
date 

Z  axis  pos  in  ECI  frame  at  Jul 
date 

Velocity  vector  in  X  direction 
Velocity  vector  in  Y  direction 
Velocity  vector  in  Z  direction 
Inclination  at  Julian  Date 
Right  Ascension  at  Julian  Date 
Eccentricity  at  Julian  Date 
Arg  of  Perigee  at  Julian  Date 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 


The  Mean  Anomanly  at  Julian  Date*/ 


The  amount  of  time  in  seconds 
that  has  transpired  between  the 
actual  ephemeris  measurements 
and  the  Julian  Date  propagated 
The  Errors  which  have  occurred 


Borland  C++  BuilderB  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


CallSGP4 (struct  Satellite  &Sat, 


double 

JulianDate, 

double 

&X, 

double 

&Y, 

double 

&Z, 

double 

&Xdot, 

double 

ScYdot, 

double 

ScZdot, 

double 

ficlnclination. 

double 

&RightAscens ion , 

double 

&Eccentricity, 

double 

&MeanMotion, 

double 

ScArgumentOf  Per  igee , 

double 

&MeanAnomaly , 

double 

&Delta, 

ErrorStructure  &ErrorList 
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B.5  The  Time  Module  Library 


The  Time  Module  Test  project  consists  of  two  modules  that  convert  back  and 
forth  between  the  Calendar  Date  and  the  Modified  Julian  Date.  These  two  modules  are 
ConvertCalendarToJuIian  and  ConvertJuIianToCalendar.  They  are  both  stored  in 
the  TimeModule.cpp  library.  Both  of  these  modules  can  be  tested  independently  with 
any  calling  routine.  The  graphical  interface  shown  in  Figure  B.4  has  been  developed  for 
this  purpose. 


Figure  B.4.  Graphical  Interface  Developed  for  Testing  the  Time  Modules 


The  code  for  this  GUI  is  contained  within  the  C++  Builder  module  TimeTestForm,  and  is 
included  in  Appendix  E. 
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B.5.1  ConvertCalenderToJulian 


The  module,  ConvertCalendarToJulian  will  take  a  date  in  the  modem 
calendar,  down  to  a  fraction  of  a  second,  and  convert  it  to  its  equivalent  Modified  Julian 
Date.  The  Modified  Julian  Date  is  simply  the  Julian  Date  -  2440000  days. 

Inputs 


int  Cyear  The  Calender  Year  (all  four  digits)  of  the  date  to  be  converted  to 
the  Modified  Julian  Date. 

int  Cmonth  The  Calender  Month  (1  to  12)  of  the  date  to  be  converted  to  the 
Modified  Julian  Date. 

int  Cday  The  Calender  Day  (1  to  366)  of  the  date  to  be  converted  to  the 
Modified  Julian  Date. 

int  Chour  The  Calender  Hour  (0  to  24)  of  the  date  to  be  converted  to  the 
Modified  Julian  Date. 

int  Cminute  The  Calender  Minute  (0  to  60)  of  the  date  to  be  converted  to  the 
Modified  Julian  Date. 

double  Csecond  The  Calender  Second  (0  -  59.99999999)  of  the  date  to  be 
converted  to  the  Modified  Julian  Date. 

Outputs 

double  &JulianDate  The  Modified  Julian  Date  converted  from  the 
Calender  Date  above. 

ErrorStructure  &ErrorList  The  error-handling  strueture. 


B.5.2  ConvertJulianToCalendar 

The  ConvertJulianToCalender  module  does  just  the  reverse  of  its  sister  module. 
It  will  take  a  Modified  Julian  Date  and  convert  it  to  its  equivalent  calender  date. 
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Inputs 


double  JulianDate  The  Modified  Julian  to  be  converted  to  an  equivalent 
Calender  Date. 

Outputs 

int  &Cyear  The  Calender  Year  (all  four  digits)  of  the  date  converted  from 
the  Modified  Julian  Date. 

int  &Cmonth  The  Calender  Month  (1  to  12)  of  the  date  converted  from  the 
Modified  Julian  Date. 

int  &Cday  The  Calender  Day  (1  to  366)  of  the  date  converted  from  the 
Modified  Julian  Date. 

int  &Chour  The  Calender  Hour  (0  to  24)  of  the  date  converted  from  the 
Modified  Julian  Date. 

int  fiCminute  The  Calender  Minute  (0  to  60)  of  the  date  converted  from  the 
Modified  Julian  Date. 

double  &Csecond  The  Calender  Second  (0  -  59.99999999)  of  the  date 
converted  from  the  Modified  Julian  Date. 

ErrorStructure  &ErrorList  The  error-handling  structure. 


B.5.3  The  TimeModule.h  Header  File 


/*  MODULE  NAME:  TimeModules . h  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  September  10, 1998  */ 
/*  */ 
/*  PURPOSE:  This  module  of  code  houses  the  Time  routines  which  are  */ 
/*  used  to  retrieve  and  manipulate  the  times  used  as  */ 
/*  reference  times  for  satellite  passing.  The  numerical  */ 
/*  algorithms  were  provided  by  Professor  William  Wiesel,  */ 
/*  Air  Force  Institute  of  Technology,  who  earlier  gleaned  */ 
/*  the  algorithms  from  the  text,  "Numerical  Recipes".  It  */ 
/*  was  converted  from  Fortran  to  C++  by  the  author.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  Builder3  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/***********★***************************★**★***★*****************************/ 
#ifndef  TimeModulesH 
#define  TimeModulesH 
/*★****★*****★★***★*★*************/ 
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/*  USER-BUILT  LIBRARIES  */ 

#include  "ErrorStructure.h” 


/* 

FUNCTION  NAME: 

ConvertCalenderTo Julian 

*/ 

/* 

AUTHOR : 

Captain  David 

Vloedman 

*/ 

/* 

DATE  CREATED: 

Septeinber  10, 

1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  function 

will  read 

in  the  calender  date  and  return  */ 

/* 

the  equivalent 

;  modified 

Julian  date. 

*/ 

/* 

*/ 

/* 

INPUTS : 

NAME: 

DEFINITION: 

*/ 

/* 

CYear 

Holds  the  calender  year 

*/ 

/* 

Cmonth 

Holds  the  Calender  month (1 

-  12)*/ 

/* 

CDay 

Holds  calender  day 

*/ 

/* 

CHour 

Holds  the  calender  hour 

/* 

CMinute 

Holds  the  calender  minute 

/* 

CSecond 

Holds  the  calender  second 

*/ 

/* 

ErrorList 

Holds  the  Errors  found 

*/ 

/* 

*/ 

/* 

OUTPUTS : 

NAME: 

DEFINITION: 

*/ 

/* 

JulianDate 

Holds  the  Julian  equivalent 

to  *  / 

/* 

the  calender  date. 

*/ 

/* 

*/ 

/* 

COMPILER : 

Borland  C++  BuilderS  Standard  version 

*/ 

/* 

This  compiler 

should  be 

used  to  compile  and  link. 

*/ 

/*  */ 
/****************************************************************************/ 
void  ConvertCalenderToJulian(int  CYear, 

int  CMonth, 
int  CDay, 
int  CHour, 
int  CMinute, 
double  Csecond, 
double  ScJulianDate, 

Errors true ture  &ErrorList) ; 


/* 

FUNCTION  NAME: 

Convert Jul ianToCalender 

*/ 

/* 

AUTHOR: 

Captain  David 

Vloedman 

*/ 

/* 

DATE  CREATED: 

September  10, 

1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  function 

will  read 

in  the  Julian  date  and  return 

*/ 

/* 

the  equivalent 

:  calender 

date. 

*/ 

/* 

*/ 

/* 

INPUTS : 

NAME: 

DEFINITION: 

*/ 

/* 

JulianDate 

Holds  the  Julian  equivalent  to 

*/ 

/* 

the  calender  date. 

*/ 

/* 

*/ 

/* 

OUTPUTS : 

NAME: 

DEFINITION: 

*/ 

/* 

CYear 

Holds  the  calender  year 

*/ 

/* 

Cmonth 

Holds  the  Calender  month (1  -  12] 

)*/ 

/* 

CDay 

Holds  calender  day 

*/ 

/* 

CHour 

Holds  the  calender  hour 

*/ 

/* 

CMinute 

Holds  the  calender  minute 

*/ 

/* 

CSecond 

Holds  the  calender  second 

*/ 

/* 

ErrorList 

Holds  the  Errors  found 

*/ 
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/*  */ 

/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 


/**★★*★********★***★**★*★******************★********************★******★**★**/ 
void  ConvertJulianToCalender (int  &CYear, 

int  &CMonth, 
int  ScCDay, 
int  ScCHour, 
int  &CMinute, 
double  &CSecond, 
double  JulianDate, 

Errors  true  ture  ScErrorList)  ; 

#endif 
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B.6  The  TLE  Input  Library 


The  TLE  Input  Library  consists  of  the  interface  module  used  to  read  all  of  the 
input  that  comes  to  the  software  package  in  the  form  of  Two-Line  Element  (TLE)  set 
files.  The  TLE  data  format  is  used  widely  to  hold  satellite  ephemeris  in  a  data  file.  It  is 
by  the  popular  software  package,  Satellite  Tool  Kit,  developed  by  Analytical  Graphics  to 
hold  satellite  information,  as  well  as  by  Air  Force  Space  Command  and  a  host  of  other 
users.  This  is  the  most  likely  format  of  the  satellite  ephemeris  data  that  must  inevitably 
be  downloaded  to  the  Preprocessor  (and  Main  processor)  for  analysis.  The  Module, 
ReadTLEFile,  is  the  module  responsible  for  reading  this  type  of  formatted  input  file  and 
loading  the  information  into  an  object  of  type  SatStructure  which  is  defined  in  the 


Figure  B.5.  Graphical  Interface  Developed  for  Testing  ReadTLEFile 
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Satellite.h  module.  ReadTLEFile  is  housed  in  the  TLEInput.cpp  library.  ReadTLEFile 
can  be  called  from  any  C++  program,  and  it  can  be  tested  using  the  Graphical 
C++Builder  module,  TLETestForm,  which  generates  the  GUI  illustrated  in  Figure  B.5. 

B.6.1  ReadTLEFile 

The  ReadTLEFile  module  is  the  module  that  reads  a  TLE  file  and  populates 
SatStructure  with  the  satellite  data  contained  inside  of  it.  The  format  of  a  sample  TLE 
file  is  shown  in  Appendix  F. 

Inputs 

char  FileName  [MAXNAMELENGTH]  The  only  input  the  ReadTLEFile  is 
the  name  of  the  TLE  file  to  be  read. 

Outputs 

stmict  SatStructure  &SatArray  SatArray  is  an  object  of  type 
SatStructure,  which  is  essentially  an  array  of  Satellite  objects.  It  is  defined  in  the 
Satellite.h  file. 

ErrorStructure  &ErrorList  The  error-handling  structure. 


B.6.2  The  TLE  Input.h  Header  File 


/* 

MODULE  NAME: 

TLEInput . h 

*/ 

/* 

AUTHOR : 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

August  18,  1998 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  module  of  code  houses  the  routines  which  input 

the  */ 

/* 

Two  Line  Element  (TLE)  sets  from  an  input  file. 

*/ 

/* 

*/ 

/* 

COMPILER: 

Borland  C++  Builder3  Standard  version 

*/ 

/* 

This  compiler  should  be  used  to  compile  and  link. 

*/ 

/* 

*/ 

/***★*********★*** ********************************************* **************/ 
tifndef  TLEInputH 
#define  TLEInputH 
# include  "LaserConstants .h" 

#include  "Satellite.h" 

# include  "ErrorStructure.h" 

/************************************ **********★***************★***★****★★★★*/ 
/***********************  FUCTIONS  *****************************/ 
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/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


FUNCTION  NAME: 
AUTHOR: 

DATE  CREATED: 

PURPOSE : 


INPUTS : 


OUTPUTS : 


COMPILER: 


ReadTLEFile 

Captain  David  Vloedman 
August  18,  1998 


This  function  will  read  in  the  information  contained  in 
an  input  file  holding  Two  Line  Element  (TLE)  sets. 

These  TLEs  hold  the  ephemeris  data  for  all  of  the 
satellites  we  will  be  covering.  It  uses  the  TLE 
information  to  populate  a  satellite  data  structure  which*/ 
is  used  throughout  the  program.  */ 

*/ 

DEFINITION:  */ 

Holds  the  name  of  the  Input  File*/ 

*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


NAME: 

FileName 

NAME: 

SatArray 

ErrorList 


DEFINITION: 

Returns  satellite  information 
Returns  error  information 


Borland  C++  BuilderS  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


*/ 


void  ReadTLEFile (char  FileName [MAXNAMELENGTH] , 
struct  SatStructure  &SatArray, 
ErrorStructure  &ErrorList) ; 

#endif 
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B.7  The  Evaluate  Ephemeris  Library 


The  purpose  of  the  Evaluate  Ephemeris  portion  of  the  preprocessor  is  to  tie 
together  all  of  the  other  modules  and  analyze  the  data  for  just  one  satellite.  This  library 
is,  therefore,  the  heart  of  the  preprocessor.  It  can  be  used  to  more  intensely  scrutinize  a 
single  satellite  engagement  for  error  checking  or  other  purposes.  The  library  contains 
three  modules,  EvaluateEphemeris,  CompareOrbit,  and  FindThetaG.  Each  module 


can  be  run  independently  as  a  stand  alone  application,  and  all  are  run  repeatedly  by  each 
execution  of  the  preprocessor.  A  Graphical  Interface  has  been  created  using  C-H-Builder 
3  to  execute  these  three  modules  using  a  single  satellite’s  ephemeris  input.  This  interface 
is  shown  in  Figure  B.6,  and  is  controlled  by  the  module,  EvaluateEphemerisForm.  The 


implementation  for  this  module  is  contained  in  Appendix  E. 


Figure  B.6.  Graphical  Interface  Used  to  Test  EvaluateEphemeris 
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B.7.1  EvaluateEphemeris 


EvalaluateEphemeris  is  the  module  that  calls  all  of  the  modules  so  far  discussed, 
including  CompareOrbit  and  FindThetaG.  It  is  the  pinnacle  module  responsible  for  tying 
together  all  of  the  data  and  algorithms  together  for  a  single  satellite  analysis.  It  is  called 
multiple  times  by  the  preprocessor  to  analyze  each  satellite  in  the  input  file  in  succession. 
This  module  is  responsible  for  determining  whether  or  not  a  satellite  is  or  will  be  in  the 
field  of  view  of  the  platform  during  a  given  time  increment. 

Inputs 


struct  Satellite  &Sat  This  first  input  is  just  the  Satellite  object 
that  holds  all  of  the  ephemeris  information  gleaned  from  a  Two-Line 
Element  Set  file,  and  populated  using  the  ReadTLEFile  module. 

struct  Aircraft  &ABLFlatfonn  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  ThetaGInRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  TimeToNextRun  The  estimated  time  until  the  next  run  of  the 
Preprocessor. 

double  iJulianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 

Outputs 

int  &SatelliteXnView  This  is  a  boolean  variable  that  tells  whether 
or  not  the  satellite  being  evaluated  is  currently  (as  of  the  Julian  Date  given)  in 
view  of  the  platform  given: 

1  =  satellite  in  view 
0  =  satellite  not  in  view 
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int  fcOrbitlnView  It  may  be  that  the  satellite  is  not  in  view,  but  its 
ephemeris,  or  the  path  the  satellite  follows,  is  currently  in  view.  This  is  regardless 
of  whether  the  satellite  itself  is  in  view.  Naturally,  if  the  satellite  is  in  view,  the 
orbit  must  also  be  in  view. 

1  =  orbit  in  view 
0  =  orbit  not  in  view 

double  &SatX  The  X  coordinate  of  the  satellite  at  the  Julian  Date 
specified,  given  in  terms  of  the  ECI  frame,  in  kilometers. 

double  &SatY  The  Y  coordinate  of  the  satellite  at  the  Julian  Date 
specified,  given  in  terms  of  the  ECI  frame,  in  kilometers. 

double  &SatZ  The  X  coordinate  of  the  satellite  at  the  Julian  Date 
specified,  given  in  terms  of  the  ECI  frame,  in  kilometers. 

double  &SatXdot  The  velocity  in  the  X  direction  (ECI  frame)  of  the 
satellite  at  the  Julian  Date  specified,  in  kilometers  per  second. 

double  CeSatYdot  The  velocity  in  the  Y  direction  (ECI  frame)  of  the 
satellite  at  the  Julian  Date  specified,  in  kilometers  per  second. 

double  &SatZdot  The  velocity  in  the  Z  direction  (ECI  frame)  of  the 
satellite  at  the  Julian  Date  specified,  in  kilometers  per  second. 

double  &Delta  This  is  the  time  that  has  elapsed  between  the  time  that  the 
original  ephemeris  data  for  the  satellite  (held  in  the  Satellite  object)  and  the  Julian 
propagation  date  specified.  In  other  words,  the  amount  of  time  (in  minutes)  that 
has  been  propagated. 

double  &Inclination  The  inclination  of  the  satellite  at  the  Julian  Date 
specified,  in  degrees. 

double  &RightAscension  The  Right  Ascension  of  the  satellite  at  the 
Julian  Date  specified,  in  degrees. 

double  &Eccentricity  The  Eccentricity  of  the  satellite  at  the  Julian  Date 
specified,  in  degrees. 

double  &MeanMotion  The  Mean  Motion  of  the  satellite  at  the  Julian  Date 
specified. 

double  &ArgrumentO£Perigee  The  Argument  of  Perigee  of  the  satellite 
at  the  Julian  Date  specified,  in  degrees. 
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double  &MeanAiiomaly  The  Mean  Anomaly  of  the  satellite  at  the  Julian 
Date  specified,  in  degrees. 

double  &I>vector  The  Dvector  is  the  vector  used  to  evaluate  the  time  to 
rise.  Its  presence  here  is  used  mostly  for  testing  purposes  and  can  be  largely 
ignored.  For  a  more  complete  explanation,  see  Chapter  2,  pages  18-31. 

double  &TimeToRise  If  the  orbit  of  the  satellite  is  in  view,  but  the  satellite 
is  not  in  view,  this  parameter  gives  the  time  estimate  of  when  the  satellite  is 
expected  to  come  into  view. 

double  &CrltlcalRadius  The  Critical  Radius  describes  the  smallest 
radius  at  the  satellites  position  that  can  appear  above  the  artificial  horizon  of  the 
platform.  This  parameter  is  also  used  mostly  for  testing,  and  can  be  disregarded 
when  called  by  other  applications.  For  a  more  complete  explanation,  see  Chapter 
2,  pages  18-31. 

double  &SatRadius  The  Sat  Radius  describes  the  radius  of  the  satellite  as 
measured  from  the  center  of  the  Earth.  This  parameter  is  also  used  mostly  for 
testing,  and  can  be  disregarded  when  called  by  other  applications.  For  a  more 
complete  explanation,  see  Chapter  2,  pages  18-31. 

ErrorStructure  &ErrorList  The  error  handling  object. 


B.7.2  CompareOrbit 

Compare  Orbit  is  the  module  used  by  EvaluateEphemeris  to  see  if  the  orbit  of  the 
satellite  is  in  view  of  the  platform. 

Inputs 


struct  Satellite  &Sat  This  first  input  is  just  the  Satellite  object 
that  holds  all  of  the  ephemeris  information  gleaned  from  a  Two-Line 
Element  Set  file,  and  populated  using  the  ReadTLEFile  module. 

struct  Aircraft  &ABLPlat£onn  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  ThetaGInRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 
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Outputs 


double  &TimeToRise  If  the  orbit  of  the  satellite  is  in  view,  but  the  satellite 
is  not  in  view,  this  parameter  gives  the  time  estimate  of  when  the  satellite  is 
expected  to  come  into  view. 

double  &CriticalRadius  The  Critical  Radius  describes  the  smallest 
radius  at  the  satellites  position  that  can  appear  above  the  artificial  horizon  of  the 
platform.  This  parameter  is  also  used  mostly  for  testing,  and  can  be  disregarded 
when  called  by  other  applications.  For  a  more  complete  explanation,  see  Chapter 
2,  pages  18-31. 


double  &SatRadius  The  Sat  Radius  describes  the  radius  of  the  satellite  as 
measured  from  the  center  of  the  Earth.  This  parameter  is  also  used  mostly  for 
testing,  and  can  be  disregarded  when  called  by  other  applications.  For  a  more 
complete  explanation,  see  Chapter  2,  pages  18-31. 

ErrorStructure  &ErrorList  The  error  handling  object. 


B.7.3  FindThetaG 

The  module,  FindThetaG,  is  used  to  propagate  the  Earth’s  rotation  in  the  ECI 
coordinate  frame  over  time.  It  requires  a  reference  position  for  the  Greenwich  Meridian, 
at  a  given  reference  time,  and  the  Modified  Julian  Date  of  the  time  that  is  to  be 
propagated  to.  It  is  important  to  remember,  that,  when  using  this  module,  the  reference 
time  and  the  propagation  date  should  not  be  more  than  a  year  apart.  If  they  are  more  than 
a  year  apart,  the  user  takes  the  chance  that  accuracy  will  fade,  making  the  angle  less 
precise. 
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Inputs 


int  ReferenceHour  Reference  hour  Refers  to  the  Reference  angle  of 

0g  (The  angle  between  the  Greenwich  meridian  and  the  Vernal  Equinox).  This 
angles  is  given  in  hours,  minutes  and  seconds  as  opposed  to  degrees  or  radians. 
This  parameter  holds  the  hours  portion  of  6g, 

int  Ref  erenceMinute  The  minutes  portion  of  6g. 

double  ReferenceSecond  The  seconds  portion  of  0g. 

double  RefModJulianDate  This  parameter  holds  the  Modified  Julian 
Date  at  which  the  reference  angle,  0g,  was  taken.  This  allows  0g  to  be  propagated 
forward  to  the  present  moment. 

int  CalcYear  The  current  year. 

int  CalcMonth  The  current  month  (1-12). 

int  CalcDay  The  current  day  (1-31). 

int  CalcHour  The  current  hour  (1-24). 

int  CalcMinute  The  current  minute  (1-60). 

double  CalcSecond  The  current  second.  This  is  the  only  part  of  the 
current  time  that  can  be  given  as  a  non-integer.  This  field  should  be  accurate  to 
at  least  three  decimal  places. 

Outputs 

double  &ThetaGInRadians  This  is  the  instantaneous  angle  between  the 
Greenwich  meridian  and  the  Vernal  Eqinox  at  the  moment  of  execution  of  the 
preprocessor. 

ErrorStructure  &ErrorList)  This  parameter  is  both  an  input  and 
output  parameter.  Each  module  uses  it  to  assess  whether  a  fatal  error  has 
occurred  somewhere  else  in  the  program,  and  uses  it  to  record  errors  which  may 
be  important  to  the  user. 
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B.7.4  The  EvaluateEpheinerisModules.h  Header  File 


/*  MODULE  NAME:  EvaluateEphemerisModules . h  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  August  18,  1998  */ 
/*  */ 
/*  PURPOSE:  This  set  of  modules  supports  the  preprocessor  and  are  */ 
/*  used  to  evaluate  whether  or  not  the  satellite  is  ever  */ 
/*  above  the  platform  horizon.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/**★*****************★******★*★******★****★********************************** ^ 
# i f nde f  Evaluat eEphemer i sModulesH 
# define  EvaluateEphemerisModulesH 

# include  "ErrorStructure.h" 

#include  "Aircraft.h" 

#include  " Satellite . h” 


/*  FUNCTION  NAME:  EvaluateEphemeris  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  Sept  19,  1998  */ 


I  *  PURPOSE : 
/* 

/* 

/* 

/* 

/*  INPUTS: 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/ *  OUTPUTS : 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


This  function  will  take  the  position  of  the  aircraft  and*/ 


the  orbital  elements  of  the  satellite  and  calculate  */ 
whether  or  not  the  satellite  ever  comes  into  view  (or  */ 
above  the  horizontal  horizon)  of  the  the  aircraft.  */ 

*/ 

NAME:  DEFINITION:  */ 

Sat  Holds  all  ephemeris  information  */ 

for  the  Satellite  being  studied  */ 
ABLPlatform  Holds  all  information  about  ABL  */ 

Platform  position/disposition  */ 
JulianDate  The  time  to  which  the  position  */ 

of  sat  should  be  propagated  to  */ 


TimeToNextRun  The  amount  of  time  for  which  the*/ 


current  run  must  last.  This  is  */ 
To  determine  how  much  time  in  */ 
seconds  will  transpire  before  */ 

next  update  is  received.  */ 

ThetaGInRadians  The  angle  between  the  Greenwich  */ 

Meridian  and  the  Vernal  Equinox  */ 
at  JulianDate.  */ 

NAME:  DESCRIPTION:  */ 

SatelliteInView  If  the  Satellite  is  visible  to  */ 

the  ABLPlatform  (over  the  */ 

artificial  horizon  of  the  */ 

aircraft.  1  =  "yes",  0  =  "no”  */ 
OrbitInView  Is  the  satellite  ever  above  the  */ 

horizon  plain  of  the  platform?  */ 
(IE,  is  the  orbit  itself,  regard*/ 
less  of  the  satellite  present  */ 
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/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


SatX 

SatY 

SatZ 

SatXdot 

SatYdot 

SatZdot 

Inclination 

RightAscension 

Eccentricity 

ArgumentOf Perigee 

Mean  Anomaly 

Delta 


Dvector 


TimeToRise 

CriticalRadius 

SatRadius 


ErrorList 

COMPILER:  Borland  C++  Builder3 

This  compiler  should 


position,  it  view?  YES=1,  NO=0.  */ 
X  axis  pos  in  ECI  frame  at  Jul  */ 
date  * / 

Y  axis  pos  in  ECI  frame  at  Jul  */ 
date  * / 

Z  axis  pos  in  ECI  frame  at  Jul  */ 
date  ★ / 

Velocity  vector  in  X  direction  */ 
Velocity  vector  in  Y  direction  */ 
Velocity  vector  in  Z  direction  */ 
Inclination  at  Julian  Date  */ 

Right  Ascension  at  Julian  Date  */ 

Eccentricity  at  Julian  Date  */ 

Arg  of  Perigee  at  Julian  Date  */ 

The  Mean  Anomanly  at  Julian  Date*/ 
The  amount  of  time  in  seconds  */ 

that  has  transpired  between  the  */ 
actual  ephemeris  measurements  */ 

and  the  Julia.n  Date  propagated  */ 
This  is  the  magnitude  of  the  */ 

satellite  radius  vector  (the  */ 

vector  from  earth  center  to  the  */ 
satellite)  in  the  direction  of  */ 

the  Platform  radius  vector.  IE  */ 
the  component  of  the  sat  radius  */ 
vector  in  the  Platform  radius  */ 
direction.  This  is  used  to  show*/ 
how  close  the  sat  is  to  rising  */ 
above  the  artificial  horizon.  */ 
Estimated  time  before  the  sat  */ 
rises  above  the  platform's  */ 

artificial  horizon.  */ 

The  Radial  component  which  tells*/ 
the  minimum  distance  an  object  */ 
must  be  before  it  lies  above  the*/ 
artificial  horizon  of  the  */ 

platform.  ★/ 

The  Radial  altitude  of  the  sat  */ 
wrt  the  platform  altitude.  This*/ 
is  compared  to  the  critical  rad  */ 
to  determine  if  the  sat  lies  */ 
above  or  below  the  platform  */ 

artificial  horizon.  */ 

The  Errors  which  have  occurred  */ 

*/ 

Standard  version  */ 

be  used  to  compile  and  link.  */ 


/  * 

'  */ 

/************************** ********************^***^^^*^*^^^^^^^^^^^^^^^^^^^^^ 
void  EvaluateEphemeris (  struct  Satellite  ficSat, 

struct  Aircraft  &Platform, 
double  ThetaGInRad, 
double  JulianDate, 
double  TimeToNextRun, 
int  &SatelliteInView, 

int  &:OrbitInView, 

double  ScSatX, 
double  &SatY, 
double  ScSatZ, 
double  ScSatXdot, 
double  &SatYdot, 
double  &SatZdot, 
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double  ScDelta, 
double  Scinclination, 
double  ScRightAscension, 
double  ScEccentricity, 
double  ScMeanMot.ion, 
double  &Ar gumen to f Perigee, 
double  ScMeanAnomaly, 
double  ScDvector, 
double  ScTimeToRise, 
double  &CriticalRadius , 
double  ScSatRadius, 
ErrorStructure  &ErrorList) ; 


FUNCTION  NAME: 
AUTHOR: 

DATE  CREATED: 


FindThetaG 

Captain  David  Vloedman 
October  6,  1998 


PURPOSE : 


This  function  will  take  a  reference  position  and  time 
for  a  known  angle  between  the  Greenwich  Meridian  and 
the  Vernal  Equinox,  and  propagate  the  angle  through 
natural  orbit  precession  at  the  given  calculation  time. 
Note  that  the  reference  time  must  always  be  BEFORE  the 
calulation  time. 


NAME: 

ReferenceHour 


ReferenceMinute 


ReferenceSecond 


Re  f ModJul ianDate 


CalcYear 

Calcmonth 

CalcDay 

CalcHour 

CalcMinute 

CalcSecond 


DEFINITION:  */ 
This  holds  the  value  of  Theta  G  */ 
at  Ref ModJul ianDate.  The  angle  */ 
of  Theta  G  is  given  in  hours,  */ 
minutes,  and  seconds  instead  of  */ 
degrees,  where  24  hrs  =  360  deg  */ 
Holds  the  minutes  of  Theta  G  at  */ 
Re f ModJul ianDate .  */ 
Holds  the  seconds  of  Theta  G  at  */ 
RefModJul ianDate .  */ 
This  is  the  reference  date  when  */ 
an  actual  observation  of  the  */ 
true  value  of  theta  G  was  made.  */ 
Holds  the  current  calender  year  */ 
Holds  the  Calender  month (1  -  12)*/ 
Holds  calender  day  */ 
Holds  the  calender  hour  */ 
Holds  the  calender  minute  */ 
Holds  the  calender  second  */ 


OUTPUTS : 


NAME: 

ThetaGInRadians 


ErrorList 


DESCRIPTION:  */ 
The  angle  between  the  Greenwich  */ 
Meridian  and  the  Vernal  Equinox  */ 
at  Calc  Date.  */ 
The  Errors  which  have  occurred  */ 


/*  COMPILER:  Borland  C++  Builder 3  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/  *  */ 

/************ ************************************** *★************************/ 
void  FindThetaG (int  ReferenceHour, 

int  ReferenceMinute, 

double  ReferenceSecond, 
double  RefModJul ianDate, 
int  CalcYear, 

int  CalcMonth, 
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int  CalcDay, 

int  CalcHour, 

int  CalcMinute, 

double  CalcSecond, 

double  &ThetaGInRadians , 

Errors true ture  &ErrorList) ; 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


FUNCTION  NAME: 
AUTHOR: 

DATE  CREATED: 

PURPOSE : 


CompareOrbit 
Captain  David  Vloedman 
October  S,  1998 


*/ 
*/ 
*/ 
*/ 

This  function  will  take  the  position  of  the  aircraft  and*/ 
the  orbital  elements  of  the  satellite  and  calculate  */ 
whether  or  not  the  satellite  ever  comes  into  view  (or  */ 
above  the  horizontal  horizon)  of  the  the  aircraft.  Note*/ 


that  this  is  at  an  instantaneous  time.  It  does  not 
account  for  the  precession  of  the  orbit,  and  so  must 
be  run  at  regular  close  (30  minute)  intervals  to  be 
reliable  and  accurate. 


INPUTS :  NAME : 

Platform. LatitudeDegree 

Platform. LatitudeMinute 

Platform. LatitudeSecond 

Platform . Longi tudeDegree 

Platform. LongitudeMinute 

Platform. LongitudeSecond 

Sat . RightAscension 

Sat .Eccentricity 

Sat . Inclination 

Sat .MeanMotion 

Sat .ArgumentOf Perigee 

Sat . MeanAnomaly 

Sat .EpochDay 

Sat . EpochYear 

ThetaGInRad 

ErrorList 


OUTPUTS : 


NAME: 

CriticalRadius 


SatRadius 


Orbit InView 


DEFINITION: 

Degree  of  Latitude  (0-90  int) 
Minute  of  Latitude  (0-60  int) 
Second  of  Latitude  (0-60  float) 
Degree  of  Longitude  (0-360  int) 
Minute  of  Longitude  (0-60  int) 
Second  of  Longitude  (0-60 
Right  Ascension  (degrees) 
Eccentricity  (float) 
Inclination  (degrees) 

Mean  Motion  (float) 

Degrees  (0-360) 

Degrees  (0-360) 

Day  of  year  msrmts  taken 
Calender  Year  (int) 

Angle  between  Greenwich  and 
Vernal  Equinox 
Errors  that  have  occured 


float) */ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 

(float) */ 
*/ 
*/ 
*/ 
*/ 
*/ 

DESCRIPTION:  ,  */ 

The  Radial  component  which  tells*/ 
the  minimiim  distance  an  object  */ 
must  be  before  it  lies  above  the*/ 
artificial  horizon  of  the  */ 

platform.  */ 

The  Radial  altitude  of  the  sat  */ 
wrt  the  platform  altitude.  This*/ 
is  compared  to  the  critical  rad  */ 
to  determine  if  the  sat  lies  */ 
above  or  below  the  platform  */ 
artificial  horizon.  */ 

Is  the  satellite  ever  above  the  */ 
horizon  plain  of  the  platform?  */ 
(IE,  is  the  orbit  itself,  regard*/ 
less  of  the  satellite  present 
position,  it  view?  YES=:1,  NO=0. 


COMPILER:  Borland  C++  Builder 3  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 
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/*  */ 
/****★**************★****★****★******************★**********★**★*************/ 
void  CompareOrbit (  struct  Satellite  &Sat, 

struct  Aircraft  ScPlatform, 
double  ThetaGInRad, 
int  ScOrbitInVieW; 
double  &CriticalRadius , 
double  ScSatRadius, 

ErrorStructure  £cErrorList)  ; 

#endif 
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B.8  The  ABLPA  Preprocessor 


The  ABL  Predictive  Avoidance  Preprocessor  is  the  culmination  of  the  modules 
discussed  in  this  chapter  thus  far.  The  purpose  of  the  Predictive  Avoidance  Preprocessor 
is  to  read  the  Two-Line  Element  (TLE)  input  file  and  screen  it  to  pick  out  any  satellites 
which  could  not  be  within  range  of  the  ABL  platform  for  a  set  time  in  the  future.  The 
TLE  set  is  an  input  file  that  contains  a  list  of  all  satellites  for  which  the  user  has  a 
concern.  Each  satellite  is  either  in  the  ABL  engagement  area,  or  outside  that  area.  The 
preprocessor  returns  a  shortened  TLE  input  file  that  contains  only  those  satellites  that  are 
within  the  engagement  area.  Unfortunately,  the  Main  Processor  must  execute  very 
quickly,  in  a  real-time  operational  role.  Therefore,  the  number  of  satellites  that  it  needs 


Figure  B.7.  The  Graphical  Interface  to  the  Preprocessor 
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to  process  should  be  as  small  as  possible.  The  preprocessor  ensures  that  this  is  so.  This 
“screening”,  in  turn,  reduces  the  execution  time  of  the  Main  Processor.  The  execution 
time  of  the  preprocessor  is  not  an  issue,  because  the  preprocessor  can  be  run  at  any  time, 
and  there  is  no  need  to  run  the  preprocessor  in  a  given  time  slot.  Despite  this  fact,  the 
ABLPA  preprocessor  generally  runs  in  under  one  second.  This  time  estimate  is  for 
running  with  a  standard  desktop  200  MHz  computer.  The  Graphical  Interface  developed 
for  the  Preprocessor  is  shown  in  Figure  B.7.  Of  course,  as  with  all  of  the  modules 
described  in  this  chapter,  the  user  of  these  libraries  could  easily  create  their  own 
graphical  (or  non-graphical)  interface,  designed  to  their  own  tastes.  This  interface  is 
simply  provided  to  make  use  of  the  preprocessor  more  convenient.  Notice  that  most  of 
the  input  and  output  is  handled  via  TLE  files.  The  format  of  a  standard  TLE  file  is  given 
in  Appendix  F.  The  final  output  file  resulting  from  the  run  of  the  preprocessor  will  serve 
as  input  file  for  the  Main  Processor.  The  next  chapter  will  describe  the  nature  of  the 
Main  Processor  and  the  way  in  which  this  output  file  will  be  put  to  use. 


B.8.1  Inputs 

char  InFileName  [MAXNAMELENGTH]  This  parameter  holds  the  name  of 
the  Two  Line  Element  Set  that  holds  the  satellites  to  be  evaluated. 

char  OutFileName  [MAXNftMELENGTHl  Holds  the  name  of  the  file  to 
which  the  output  satellites’  Two-Line  Element  set  information  is  routed  to.  This 
file  holds  all  of  the  satellites  that  have  been  judged  by  the  Preprocessor  to  be  “in 
view”  of  the  platform. 

struct  Aircraft  &ABLPlat£onn  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of  the  Preprocessor. 

int  ReferenceHour  Reference  hour  Refers  to  the  Reference  angle  of  0g 
(The  angle  between  the  Greenwich  meridian  and  the  Vernal  Equinox).  This 
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angles  is  given  in  hours,  minutes  and  seconds  as  opposed  to  degrees  or  radians. 
This  parameter  holds  the  hours  portion  of  6g, 

int  Ref  erenceMinute  The  minutes  portion  of  6g. 

double  Ref  erenceSecond  The  seconds  portion  of  6g. 

double  RefModJulianDate  This  parameter  holds  the  Modified  Julian 
Date  at  which  the  reference  angle,  0g,  was  taken.  This  allows  6g  to  be  propagated 
forward  to  the  present  moment. 

int  CalcYear  The  current  year. 

int  CalcMonth  The  current  month  (1-12). 

int  CalcDay  The  current  day  (1-31). 

int  CalcHour  The  current  hour  (1-24). 

int  CalcMinute  The  current  minute  (1-60). 

double  CalcSecond  The  current  second.  This  is  the  only  part  of  the 
current  time  that  can  be  given  as  a  non-integer.  This  field  should  be  accurate  to 
at  least  three  decimal  places. 

double  TimeToNextRun  The  estimated  time  until  the  next  run  of  the 
Preprocessor. 

ErrorStructure  &ErrorList  This  parameter  is  both  an  input  and 
output  parameter.  Each  module  uses  it  to  assess  whether  a  fatal  error  has 
occurred  somewhere  else  in  the  program,  and  uses  it  to  record  errors  that  may  be 
important  to  the  user. 

B.8.2  Outputs 

int  &InFileLength  This  parameter  tells  the  user  how  many 

elements  were  read  in  from  the  file  specified  by  the  input  parameter 
“InFileName[MAXNAMELENGTH]”.  This  is  the  total  number  of  satellites  that 
were  evaluated  during  the  run  of  the  Preprocessor. 

int  &OutFileLength  This  parameter  tells  the  user  how  many 

elements  were  written  to  the  file  specified  by  the  input  parameter 
“OutFileName[MAXNAMELENGTH]”.  This  is  the  total  number  of  satellites 
that  were  judged  to  be  “in-view”  of  the  platform  between  the  time  of  the  run  and 
the  next  run  of  the  preprocessor. 
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double  &ThetaGInDegrees  This  is  the  instantaneous  angle  between  the 
Greenwich  meridian  and  the  Vernal  Eqinox  at  the  moment  of  execution  of  the 
preprocessor. 

ErrorStructure  &ErrorList  This  parameter  is  both  an  input  and 
output  parameter.  Each  module  uses  it  to  assess  whether  a  fatal  error  has 
occurred  somewhere  else  in  the  program,  and  uses  it  to  record  errors  which  may 
be  important  to  the  user. 
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B.8.3  The  PAPreprocessor.h  Header  File 


/* 

MODULE  NAME: 

/* 

AUTHOR : 

/* 

DATE  CREATED 

/* 

/* 

PURPOSE: 

/* 

/* 

/* 

/* 

COMPILER: 

/* 

/* 

PAPreprocessor 
Captain  David  Vloedman 
August  18,  1998 

This  set  of  modules  supports /composes  the  preprocessor 
used  to  evaluate  whether  or  not  the  satellites  are  ever 
above  the  platform  horizon. 

Borland  C++  Builder3  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 

#ifndef  PAPreprocessorH 
#define  PAPreprocessorH 


/★**********★****★*★*********★******★★**★******★**********************★****★*/ 
/*  FUNCTION  NAME:  PAPreprocessor  */ 

/*  AUTHOR:  Captain  David  Vloedman  */ 

/*  DATE  CREATED:  October  6,  1998  */ 

/*  ’  */ 

/*  PURPOSE:  This  procedure  will  read  in  an  input  file  of  Two  Line  */ 

/*  Element  (TLE)  sets  and  perform  an  analysis  to  determine  */ 

/*  whether  or  not  they  are  within  view  of  the  airborne  */ 

/*  platform.  If  a  satellite  is  in  view,  it  will  be  added  */ 


/* 

to  the  ouput  file. 

/* 

processor. 

/* 

/ *  INPUTS : 

NAME: 

/* 

InFileName 

/* 

OutFileName 

/* 

InFileLength 

/* 

ABLPlatform 

/* 

/* 

ReferenceHour 

/* 

/* 

/* 

/* 

/* 

ReferenceMinute 

/* 

/* 

ReferenceSecond 

/* 

/* 

RefModJulianDate 

/* 

/* 

/* 

CalcYear 

/* 

Calcmonth 

/* 

CalcDay 

/* 

CalcHour 

/* 

CalcMinute 

/* 

CalcSecond 

which  is  the  input  file  for  the  main  */ 

*/ 

*/ 

DEFINITION:  */ 

Holds  name  of  the  satellite  file*/ 
File  that  holds  the  sats  in  view*/ 
The  total  number 

Holds  all  information  about  ABL  */ 
Platform  position/disposition  */ 
This  holds  the  value  of  Theta  G  */ 
at  RefModJulianDate.  The  angle  */ 
of  Theta  G  is  given  in  hours,  */ 
minutes,  and  seconds  instead  of  */ 
degrees,  where  24  hrs  =  360  deg  */ 
Holds  the  minutes  of  Theta  G  at  */ 
RefModJulianDate.  */ 

Holds  the  seconds  of  Theta  G  at  */ 
RefModJulianDate .  * / 

This  is  the  reference  date  when  */ 
an  actual  observation  of  the  */ 
true  value  of  theta  G  was  made.  */ 
Holds  the  current  calender  year  */ 
Holds  the  Calender  month (1  -  12)*/ 

Holds  calender  day  */ 

Holds  the  calender  hour  */ 

Holds  the  calender  minute  */ 

Holds  the  calender  second  */ 
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/* 

TimeToNextRun 

/* 

/* 

/* 

/* 

/* 

/*  OUTPUTS: 

NAME: 

/* 

InFileLength 

/* 

/* 

/* 

OutFileLength 

/* 

/* 

/* 

ThetaGInDegrees 

/* 

/* 

/* 

ErrorList 

/* 

The  amount  of  time  for  which  the*/ 


current  run  must  last.  This  is  */ 
To  determine  how  much  time  in  */ 
seconds  will  transpire  before  */ 
next  update  is  received.  */ 

*/ 

DESCRIPTION:  */ 
The  total  number  of  satellites  */ 
that  have  been  evaluated  in  the  */ 
InFile  */ 
The  total  number  of  satellites  */ 


that  are  in  view  of  the  platform*/ 
and  have  been  put  in  the  outfile*/ 
The  rotation  angle  between  the  */ 
Earth's  current  ECEF  position  */ 
and  its  ECI  position.  */ 
Errors  that  have  occured  */ 

*/ 


/* 

THE  FINAL  OUTPUT 

IS 

/* 

WRITTEN  DIRECTLY 

TO 

/* 

MAIN  PROCESSOR. 

/* 

THE  ACTUAL  OUTFILE  ITSELF  WHICH  IS  */ 
DISK  SO  IT  CAN  BE  ACCESSED  BY  THE  */ 

*/ 

*/ 


/* 

/* 

/* 

/  *  ★ 


COMPILER:  Borland  C++  BuilderS  Standard  version  */ 

This  compiler  should  be  used  to  compile  and  link.  */ 

*/ 

**************************************************************************/ 


PAPreprocessor ( 


char 

InFileName[MAXNAMELENGTH]  , 

char 

OutFileName  [MAXNAMELENGTH] 

int 

&InFileLength, 

int 

&OutFileLength, 

struct 

Aircraft  ScPlatform, 

int 

Ref erenceHour , 

int 

ReferenceMinute, 

double 

Ref erenceSecond , 

double 

RefModJul ianDate , 

int 

CalcYear , 

int 

CalcMonth, 

int 

CalcDay, 

int 

CalcHour , 

int 

CalcMinute, 

double 

CalcSecond, 

double 

TimeToNextRun , 

double 

ficThetaGInDegrees , 

ErrorStructure  &ErrorList) ; 

#endif 
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Appendix  C.  ABLPA  Main  Processor  Software  implementation 


The  Airborne  Laser  Predictive  Avoidance  (ABL-PA)  Main  Processor  is  the 
second  of  two  software  packages  developed  in  this  project.  Figure  C.l  illustrates  how  the 
Main  Processor  fits  into  the  overall  hierarchy  of  the  software. 


A  TLEFile  containing 
the  satellites  that  have 
been  determined  will 
intersect  the  laser  in  a 
given  time. 


TLE  Input  File  From 
Space  Command 


(All  Active  Satellites) 


Situation  Inputs 
Time,  Platform 
Position,  etc. 


ABLPA 

Preprocessor 

ABLPA 

Pr  processor 

- ► 

Output 

Main  Processor 

A  TLE  File  containing 
only  those  satellites  that 
are  in  view  of  the 
platform  during  a  given 
time  period. 


A  TLE  File  containing 
the  satellites  that  are 
close  enough  to 
interpolate. 


Figure  c.l  Where  the  ABLPA  Main  Processor  Fits  in  the  Software 

Hierarchy 


It  can  be  seen  that  the  task  of  the  Main  Processor  is  to  take  the  output  file  containing  all 
active  satellites  in  view  of  the  platform,  and  create  two  output  files.  The  first  output  file 
will  contain  all  of  the  satellites  that  are  forecast  to  be  intersected  by  the  laser  during  the 
laze  duration.  The  Processor  also  creates  an  output  file  containing  the  satellites  that  pass 
closely  enough  to  the  laser  path  to  be  “interpolated”,  or  analyzed,  but  may  or  may  not 
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actually  intersect  the  laser.  This  second  “close-approach”  file  is  used  more  for  testing 
and  verification  than  operational  use.  Statistically,  more  often  than  not  the  Intersection 
File  will  be  empty  after  a  full  Main  Processor  run-through,  because  the  chances  of 
“hitting”  a  satellite  (even  with  a  theoretical  error-angle)  is  slim.  This  close  approach  file 
can  be  used  to  verify  the  successful  run  and  processing  of  the  Main  Processor.  Both 
output  files  have  exactly  the  same  format  as  the  main  TLE  file,  except  they  have  fewer 
(or  no)  satellites  within  them. 


Figure  C.2  ABLPA  Main  Processor  Calling  Tree 


C.l  Main  Processor  Modular  Format 

The  Processor  is  a  conglomeration  of  many  software  libraries  that  were  created 
and  tested  independently  before  being  combined  to  form  the  Processor.  Figure  C.2 
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shows  the  basic  modules  that  comprise  the  processor,  and  their  grouping  into  “libraries”. 
Each  module  and  library  shown  will  be  explained  within  this  chapter.  Five  of  the 
libraries  shown  in  the  Figure  have  already  been  discussed  in  Chapter  V.  These  libraries 


Table  C.1  The  Six  Remaining  Libraries  Composing  the  ABLPA  Main 

Processor 


Sub-Project 

Title 

Modules  Tested 
(C++) 

GUI  Interface 
Module 

(C++  Builder  3) 

Purpose 

ABLPA  Main 
Processor 

All  processor  modules  as 
shown  in  Figure  C.2 

PAMainProcessorForm 

To  provide  a  user- 
friendly  way  to  run 
the  processor 

Target 

Platform 

TargetPlatform 

T  argetPlatformForm 

To  find  the 
instantaneous 
position,  velocity 
and  acceleration  of 
the  platform,  and 
generate  the  REN 
conversion  matrix 

Target 

Laser 

TargetLaser 

TestT  argetLaserForm 

To  find  the 
position,  velocity 
and  acceleration 
vectors  of  the  laser 

Target 

Satellite 

TargetSatellite 

T  argetSatelliteForm 

To  get  position  and 
velocity  of  satellite 
from  SGP4,  and 
compute  satellites 
acceleration 

Find 

Displacement 

Angles 

FindDisplacementAngles 

FindErrorAngle 

FindSeparationAngle 

FindDisplacementAngle 

-Form 

To  find  the 
separation  angle 
between  the  laser 
and  the  satellite 

Process 

Satellite 

ProcessSatellite 

FindDisplacementAngles 

-Again 

T  argetPlatformAgain 

ProcessSatelliteForm 

To  pull  together  all 
of  the  other 
modules  and 
completely  process 
one  satellite,  first 
forecasting  a  close 
approach  angle, 
then  interpolating, 
if  necessary 
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are  the  Core  Modules,  the  Error  Structure,  TLE  Input,  Time  Modules,  SGP4  Support 
Modules,  and  the  Evaluate  Ephemeris  Modules.  They  will  not  be  covered  again  here. 
The  libraries  that  have  not  yet  been  discussed  are  listed  in  Table  C.l.  Each  of  these 
libraries  are  also  a  project  in  and  of  themselves,  tested  using  the  GUI  as  seen  in  the  table. 
The  discussion  of  the  preprocessor  will  progress  through  each  of  these  libraries 
individually,  discussing  the  nature  of  the  function  served  by  the  software  library,  as  well 
as  comments  on  each  module  within  that  library.  The  interfaces  and  input/output 
parameters  used  with  each  module  will  be  emphasized.  The  actual  code  for  each  module 
in  the  ABLPA  Main  Processor  will  be  listed  out  in  Appendix  D.  The  code  for  each 
library-testing  GUI  interface  will  be  listed  in  Appendix  E.  Only  the  “Header  File”  or  the 
files  with  the  “.h”  extension  will  be  listed  here  in  the  discussion,  because  they  are  short 
and  contain  important  interface  information  that  should  be  discussed.  All  of  the 
implementation  code  will  be  included  in  their  respective  Appendices. 

C.2  The  Target  Platform  Library 

The  Target  platform  Library  holds  the  module  responsible  for  processing  all 
information  pertaining  to  the  platform.  This  module  is  TargetPlatform.  The 
TargetPlatform  module  can  be  run  by  itself  using  the  Graphical  User  Interface  (GUI) 
created  as  a  front-end  to  the  module  for  testing  purposes.  This  GUI,  Shown  in  Figure 
C.3,  is  run  using  the  Borland  C-H-  Builder  module  TargetPlatformForm. 
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C.2.1  TargetPlatform 


The  TargetPlatform  Module  serves  three  main  functions.  The  first  task  performed 
by  this  module  is  to  find  the  instantaneous  position,  velocity,  and  acceleration  of  the 
platform  at  the  time  specified,  in  the  ECI  coordinate  frame.  The  second  task  is  to 
calculate  the  elements  of  the  ECI-to-REN  conversion  matrix.  Recall  that  the  Radial-East- 
North  (REN)  coordinate  frame  rotates  with  the  platform,  and  so  should  be  found  when 


Figure  C.3.  The  Graphical  Interface  Used  to  Test  TargetPlatform 


other  platform  calculations  are  made.  This  conversion  matrix,  which  is  passed  element 
by  element  in  the  parameter  list  (for  clarity),  is  used  to  rotate  all  of  the  satellite  vectors  to 
the  REN  frame  as  well,  and  so  must  be  made  available  to  the  TargetSatellite  library  as 
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well.  The  third  function  performed  by  TargetPlatform  is  to  rotate  each  of  its  output  ECI 
platform  motion  vectors  into  the  REN  frame,  and  output  the  resulting  REN  motion 
vectors  in  the  parameter  list  as  well.  This  makes  for  a  rather  long  and  unsightly 
parameter  list.  However,  this  is  preferable  to  incorporating  everything  into  a  larger 
structure,  to  allow  a  more  “instructive”  interface. 

Inputs 


struct  Aircraft  &ABLPlatf orm  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  ThetaGinRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  iJulianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 

Outputs 

double  &Plat£onnECIRhoX  The  current  ECI  X  position  vector  of  the 
position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
latitude  and  longitude  given  in  the  Aircraft  structure  input. 

double  &Plab£onnECIRboY  The  current  ECI  Y  position  vector  of  the 
position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
latitude  and  longitude  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoZ  The  current  ECI  Z  position  vector  of  the 
position  pf  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
latitude  and  longitude  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoXDot  The  current  ECI  X  velocity  vector  of 
the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECEF  velocities  given  in  the  Aircraft  structure  input. 
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double  &PlatfonnECIRboYDot  The  current  ECI  Y  velocity  vector  of 
the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECEF  velocities  given  in  the  Aircraft  structure  input. 

double  &PlatfonnECIRhoZDot  The  current  ECI  Z  velocity  vector  of  the 
velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
ECEF  velocities  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoXDotDot  The  current  ECI  X  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  only.  It  is  assumed  that  the 
aircraft  itself  is  maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnECIRhoYDotDot  The  current  ECI  Y  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  only.  It  is  assumed  that  the 
aircraft  itself  is  maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnECIRhoZDotDot  The  current  ECI  Z  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  only.  It  is  assumed  that  the 
aircraft  itself  is  maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnRENRhoR  The  current  REN  R  (Radial)  position  vector 
of  the  position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  ECI  position  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoE  The  current  REN  E  (East)  position  vector  of 
the  position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECI  position  vector,  rotated  into  the  REN  frame. 

double  &Plat£orxnRENlUioN  The  current  REN  N  (North)  position  veetor 
of  the  position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  ECI  position  vector,  rotated  into  the  REN  frame. 

double  ftPlatformRENRhoRDot  The  current  REN  R  (Radial)  velocity 
vector  of  the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  ECI  velocity  vector,  rotated  into  the  REN  frame. 

double  tcPlatfomiRENRhoEDot  The  current  REN  E  (East)  velocity 
vector  of  the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  ECI  velocity  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoNDot  The  current  REN  N  (North)  velocity 
vector  of  the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  ECI  velocity  vector,  rotated  into  the  REN  frame. 
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double  &Plat£onnRENRhoRDotDot  The  current  REN  R  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  derived  in  the  ECI  frame 
and  rotated  into  the  REN  frame.  It  is  assumed  that  the  aircraft  itself  is 
maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£oxinRENRhoEDotDot  The  current  REN  E  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  derived  in  the  ECI  frame 
and  rotated  into  the  REN  frame.  It  is  assumed  that  the  aircraft  itself  is 
maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnRENRhoNDotDot  The  current  REN  N  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  derived  in  the  ECI  frame 
and  rotated  into  the  REN  frame.  It  is  assumed  that  the  aircraft  itself  is 
maintaining  straight  and  level  flight  at  constant  velocity. 

double  &ECXtoRENMatrixll  This  an  element  (row  1,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrixl2  This  an  element  (row  1,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrixl3  This  an  element  (row  1,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix21  This  an  element  (row  2,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix22  This  an  element  (row  2,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix23  This  an  element  (row  2,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix31  This  an  element  (row  3,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 
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doxible  &ECItoRENMatrix32  This  an  element  (row  3,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix33  This  an  element  (row  3,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 


C.2.2  The  TargetPlatforin.h  Header  File 


#ifndef  TargetPlatformH 
#define  TargetPlatformH 


/*  MODULE  NAME:  TargetPlatf orm. cpp  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  January  13, 1998  */ 
/*  */ 
/*  PURPOSE:  This  set  of  modules  supports  the  processor  and  are  */ 
/*  used  to  establish  the  platform's  position,  velocity,  and*/ 
/*  acceleration  wrt  the  platform  in  the  REN  frame.  The  */ 
/*  ECI  to  REN  conversion  matrix  is  also  passed  back  to  */ 
/*  allow  other  conversions  later.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/********★******★*********★******************** ***************************^^^^ 
/*********************************/ 

/*  C++BUILDER~SPECIFIC  LIBRARIES  */ 

/********★★*★*********************/ 

#include  <vcl.h> 

#pragma  hdrstop 

#pragma  package (smart_init) 

/***★**************★*****★★****★**/ 

/*  USER-BUILT  LIBRARIES  */ 

/********★****★*******************/ 

# include  "LaserConstants .h" 

#include  "Aircraf t .h" 

# include  "ErrorStructure . h" 

#include  "TargetPlatform. h" 

/***********★*****★*************** y 

/*  C  STANDARD  LIBRARIES  */ 

/***********************★*********/ 

#include  <stdio.h> 

# include  <stdlib.h> 
iinclude  <string.h> 

#include  <iostream.h> 

#include  <conio.h> 

# include  <math.h> 
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^***********************  FUCT IONS  *****************************  j 


/* 

FUNCTION  NAME: 

TargetPlatform 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

/* 

/* 

DATE  CREATED: 

November  17,  1998 

*/ 

the  position  of  the  aircraft  and*/ 

PURPOSE : 

This  function  will  take 

/* 

position, velocity  and  acceleration  in  the  REN  frame  of  */ 

/* 

the  Airborn  laser  platform.  */ 

/* 

/* 

INPUTS : 

NAME: 

*/ 

DEFINITION:  */ 

/* 

/* 

ABLPlatform 

for  the  Satellite  being  studied  */ 
Holds  all  information  about  ABL  */ 

/* 

/* 

JulianDate 

Platform  position/disposition  */ 

The  time  to  which  the  position  */ 

/* 

/* 

OUTPUTS : 

NAME: 

of  sat  should  be  propagated  to  */ 
DESCRIPTION:  */ 

/* 

PlatformECIRhoX 

X  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

PlatformECIRhoY 

date  of  X  pos  vector  */ 

Y  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

PlatformECIRhoZ 

date  of  Y  pos  vector  */ 

Z  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

P 1 a t f ormEC IRhoXDo t 

date  of  Z  pos  vector  */' 

X  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

PlatfoCTnECIRhoYDot 

date  of  X  vel  vector  */ 

Y  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

PlatformECIRhoZDot 

date  of  Y  vel  vector  */ 

Z  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

Plat f ormEC IRhoXDo tDot 

date  of  Z  vel  vector  */ 

X  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

PlatformECIRhoYDotDot 

date  of  X  acc  vector  */ 

Y  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

Plat formECIRhoZDo tDot 

date  of  Y  acc  vector  */ 

Z  magnitude  in  ECI  frame  at  Jul  */ 

/* 

/* 

PlatformRENRhoR 

date  of  Z  acc  vector  */ 

Radial  component  in  Radial,  East*/ 

/* 

/* 

/* 

/* 

PlatformRENRhoE 

North  coordinate  frame  of  the  */ 
Rho  vector  descibed  above  in  the*/ 
ECI  frame  */ 
East  component  in  Radial,  East  */ 

/* 

/* 

/* 

/* 

P 1 a t f ormRENRhoN 

North  coordinate  frame  of  the  */ 
Rho  vector  descibed  above  in  the*/ 
ECI  frame  */ 
North  component  in  Radial,  East  */ 

/* 

/* 

/* 

/* 

PlatformRENRhoRDot 

North  coordinate  frame  of  the  */ 
Rho  vector  descibed  above  in  the*/ 
ECI  frame  */ 
Radial  Velocity  in  Radial,  East  */ 

/* 

/* 

/* 

/* 

PlatformRENRhoEDot 

North  coordinate  frame  of  the  */ 
Rho  vector  descibed  above  in  the*/ 
ECI  frame  */ 
East  velocity  in  Radial,  East  */ 

/* 

/* 

/* 

/* 

PlatformRENRhoNDot 

North  coordinate  frame  of  the  */ 
Rho  vector  descibed  above  in  the*/ 
ECI  frame  */ 
North  velocity  in  Radial,  East  */ 

/* 

/* 

/* 

/* 

PlatformRENRhoRDotDot 

North  coordinate  frame  of  the  */ 
Rho  vector  descibed  above  in  the*/ 
ECI  frame  */ 
Radial  accel .  in  Radial,  East  */ 
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/*  North  coordinate  frame  of  the  */ 
/*  Rho  vector  descibed  above  in  the*/ 
/*  ECI  frame  */ 
/*  Platf ormRENRhoEDotDot  East  accel.  in  Radial,  East  */ 
/*  North  coordinate  frame  of  the  */ 
/*  Rho  vector  descibed  above  in  the*/ 
/*  ECI  frame  */ 
/*  PlatformRENRhoNDotDot  North  accel.  in  Radial,  East  */ 
/*  North  coordinate  frame  of  the  */ 
/*  Rho  vector  descibed  above  in  the*/ 
/*  ECI  frame  */ 
/*  ECItoRENMatrixXY  The  ECI  to  REN  conversion  matrix*/ 
/*  ErrorList  The  Errors  which  have  occurred  */ 
/*  */ 
/*  COMPILER:  Borland  C++  Builder 3  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/************************************** *******  **************** *********★*****/ 

void  TargetPlatform( struct  Aircraft  ScPlatform, 
double  &ThetaGInRad, 
double  JulianDate, 
double  ScPlatformECIRhoX, 
double  ScPlatf ormECIRhoY, 
double  &PlatformECIRhoZ, 
double  &PlatformECIRhoXDot , 
double  &PlatformECIRhoYDot , 
double  ScPlatformECIRhoZDot , 
double  ScPlatformECIRhoXDotDot, 
double  &PlatformECIRhoYDotDot, 
double  ScPlatf ormECIRhoZDotDot, 
double  ScPlatformRENRhoR, 
double  &PlatformRENRhoE, 
double  ScPlatforraRENRhoN, 
double  ScPlatf ormRENRhoRDot, 
double  ScPlatformRENRhoEDot , 
double  ScPlatformRENRhoNDot , 
double  ScPlatformRENRhoRDotDot , 
double  ScPlatf  ormRENRhoEDotDot, 
double  ScPlatformRENRhoNDotDot, 
double  ScECItoRENMatrixll, 
double  5cECItoRENMatrixl2 , 
double  ScECItoRENMatrixl3, 
double  ScECItoRENMatrix21, 
double  ScECItoRENMatrix22, 
double  ScECItoRENMatrix23 , 
double  ScECItoRENMatrixll, 
double  ScECItoRENMatrix32 , 
double  ScECItoRENMatrix33, 

ErrorStructure  ScErrorList)  ; 

#endif 
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C.3  The  Target  Laser  Library 

The  Target  Laser  Library  houses  all  code  that  tranforms  the  lasers  inputs,  in  terms 
of  azimuth  and  acceleration,  into  a  position,  velocity  and  acceleration  vector  in  the  REN 
coordinate  frame.  TargetLaser,  the  module  in  this  library  responsible  for  accomplishing 
this  task,  can  be  run  independently  from  the  Processor  using  the  Graphical  Interface 
shown  in  Figure  C.4.  This  interface  is  handled  by  the  C++  Builder  module, 
TargetLaserForm,  the  code  for  which  is  listed  in  Appendix  E. 


Figure  C.4.  GUI  Used  to  Run  and  Test  TargetLaser 


C.3.1  TargetLaser 

TargetLaser  is  the  module  responsible  for  finding  the  lasers  turrets  position, 
velocity,  and  acceleration  in  the  REN  frame.  As  such,  it  takes  inputs  in  terms  of  azimuth 
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and  acceleration,  and  converts  to  a  unit  position  vector,  a  velocity  vector,  and  an 


acceleration  vector  in  the  REN  frame. 

Inputs 


double  AzimuthliiDegrees  The  current  azimuth  of  the  laser  turret  in 
degrees. 

double  ElevationInDegrees  The  current  elevation  of  the  laser  turret  in 
degrees. 

double  AzimuthDot  The  current  rate  of  change  of  the  azimuth  of  the  laser 
turret  in  degrees  per  second. 

double  ElevationDot  The  current  rate  of  change  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  AzimuthDot  Dot  The  current  acceleration  of  the  azimuth  of  the 
laser  turret  in  degrees  per  second. 

double  ElevationDot  Dot  The  current  acceleration  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 


Outputs 

double  &LaserRENRhoRPtr  The  current  REN  R  (Radial)  unit  position 
vector  of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation. 

double  &LaserRENRhoEPtr  The  current  REN  E  (East)  unit  position 
vector  of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation. 

double  &LaserRENRhoNPtr  The  current  REN  N  (North)  unit  position 
vector  of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation 

double  &LaserRENlUioRDotPtr  The  current  REN  R  (Radial)  velocity 
vector  of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 
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doxible  &LaserRENRhoEDotPtr  The  current  REN  E  (East)  velocity 
vector  of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoNDotPtr  The  current  REN  N  (North)  velocity 
vector  of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoRDotDotPtr  The  current  REN  R  (Radial) 
acceleration  vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as 
derived  from  the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and 
elevation,  and  the  acceleration  of  the  azimuth  and  elevation. 

double  &LaserRENHhoEDotDotPtr  The  current  REN  E  (East) 
acceleration  vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as 
derived  from  the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and 
elevation,  and  the  acceleration  of  the  azimuth  and  elevation. 

double  &LaserRENRhoNDotDotPtr  The  current  REN  N  (North) 
acceleration  vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as 
derived  from  the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and 
elevation,  and  the  acceleration  of  the  azimuth  and  elevation. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 


C.3.2  The  TargetLaser.h  Header  File 


tifndef  TargetLaserH 
#define  TargetLaserH 

/★**********★***★*****★*************************★**************************** ^ 


/*  MODULE  NAME:  TargetLaser . cpp  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  January  11, 1999  */ 
/*  */ 
/*  PURPOSE:  This  set  of  modules  supports  the  processor  and  are  */ 
/*  used  to  evaluate  whether  or  not  the  satellite  is  ever  */ 
/*  above  the  platform  horizon.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/****★*****★*****★******★**★★******★***************************************** ^ 
/***★***************★**********★**/ 

/*  C++BUILDER-SPECIFIC  LIBRARIES  */ 

/*******•*★★*******★********★***★**  ! 

# inc lude  <vc 1 . h> 
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#pragma  hdrstop 
#pragina  package  ( smart__init ) 
/*★**************★******★*********/ 
/*  USER-BUILT  LIBRARIES  */ 

/******************★★*************/ 
#include  “LaserConstants .h” 

# include  " Error Structure .h" 

# include  "TargetLaser .h" 


^******************************** 
/*  C  STANDARD  LIBRARIES 
/******************************** 
tinclude  <stdio,h> 

# include  <stdlib,h> 

#include  <string.h> 
ttinclude  <iostream. h> 

#include  <conio.h> 

# include  <inath.h> 


*/ 

*/ 

*/ 


/******★*****★***★*★***★★★*****★***★*★***★********★******★*★*****★***********/ 

/* 

FUNCTION  NAME: 

TargetLaser 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

January  3,  1999 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  routine  finds  the 

unit  direction  vector  of  the 

*/ 

/* 

laser  turret  given  its 

reported  azimuth  and  elevation. 

*/ 

/* 

*/ 

/* 

INPUTS : 

NAME: 

DEFINITION: 

*/ 

/* 

Az  imuth 

This  is  the  Azimuth  (reported  in*/ 

/* 

degrees  east  of  north)  of  the 

*/ 

/* 

laser  turret. 

*/ 

/* 

Elevation 

This  is  the  Elevation  (reported 

*/ 

/* 

in  degrees  above  horizon)  of  the*/ 

/* 

laser  turret. 

*/ 

/* 

AzimuthDot 

This  is  the  Azimuth  rate  of 

*/ 

/* 

change  of  the  laser  turret. 

*/ 

/* 

AzimuthDot 

This  is  the  Elevation  rate  of 

*/ 

/* 

change  of  the  laser  turret. 

*/ 

/* 

AzimuthDotDot 

This  is  the  Azimuth  acceleration*/ 

/* 

of  the  laser  turret. 

*/ 

/* 

AzimuthDotDot 

This  is  the  Elevation  accel . 

*/ 

/* 

/  ^ 

of  the  laser  turret. 

*/ 

/* 

OUTPUTS : 

NAME: 

DESCRIPTION: 

*/ 

*/ 

/* 

LaserRENRhoR 

The  unit  Radial  component  of  the 

!*/ 

/* 

position  vector  given  in  the 

*/ 

/* 

REN  (Radial,  East,  North)  coord 

*/ 

/* 

frame  which  is  centered  on  the 

*/ 

/* 

platform. 

*/ 

/* 

LaserRENRhoE 

The  unit  East  component  of  the*/ 

/* 

position  vector  given  in  the 

*/ 

/* 

REN  (Radial,  East,  North)  coord 

*/ 

/* 

frame  which  is  centered  on  the 

^/ 

/* 

platform. 

*/ 

/* 

Las  er RENRhoN 

The  unit  North  component  of  the* 

/ 

/* 

position  vector  given  in  the 

*/ 

/* 

REN  (Radial,  East,  North)  coord 

*/ 

/* 

frame  which  is  centered  on  the 

*/ 

/* 

platform. 

*/ 

/* 

LaserRENRhoRDot 

The  unit  Radial  velocity  of  the 

*/ 
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/* 

/* 

/* 

/* 


/* 

LaserRENRhoEDot 

/* 

/* 

/* 

/* 

/* 

LaserRENRhoNDot 

/* 

/* 

/* 

f* 

/* 

LaserRENRhoRDotDot 

/* 

/* 

/* 

/* 

/* 

Las  erRENRhoEDo  tDo  t 

/* 

/* 

/* 

/* 

/* 

Las  erRENRhoNDo  tDo  t 

/* 

/* 

/* 

/* 

/* 

ErrorList 

/* 

' 

/*  COMPILER: 

Borland  C++  Builder! 

/* 

This  compiler  should 

position  vector  given  in  the  */ 
REN  (Radial,  East,  North)  coord  */ 
frame  which  is  centered  on  the  */ 
platform.  */ 

The  unit  East  velocity  of  the  */ 
position  vector  given  in  the  */ 
REN  (Radial,  East,.  North)  coord  */ 
frame  which  is  centered  on  the  */ 
platform.  */ 

The  unit  North  velocity  of  the  */ 
position  vector  given  in  the  */ 
REN  (Radial,  East,  North)  coord  */ 
frame  which  is  centered  on  the  */ 
platform.  */ 

The  unit  Radial  accel.  of  the  */ 
position  vector  given  in  the  */ 
REN  (Radial,  East,  North)  coord  */ 
frame  which  is  centered  on  the  */ 
platform.  */ 

The  unit  East  accel.  of  the  */ 

position  vector  given  in  the  */ 
REN  (Radial,  East,  North)  coord  */ 
frame  which  is  centered  on  the  */ 
platform.  */ 

The  unit  North  accel.  of  the  */ 
position  vector  given  in  the  */ 
REN  (Radial,  East,  North)  coord  */ 
frame  which  is  centered  on  the  */ 
platform.  */ 

The  Errors  which  have  occurred  */ 

*/ 

Standard  version  */ 

be  used  to  compile  and  link.  */ 


/*  */ 
/*★*****★*★***★*★********★**★***★***********★********★*★*************★*******/ 
void  Targe tLaser (double  AzimuthInDegrees , 

double  ElevationInDegrees , 
double  AzimuthDot, 
double  ElevationDot, 
double  AzimuthDotDot , 
double  ElevationDotDot , 
double  &LaserRENRhoRPtr , 
double  ScLaserRENRhoEPtr , 
double  &LaserRENRhoNPtr , 
double  &LaserRENRhoRDotPtr , 
double  ScLaserRENRhoEDotPtr , 
double  ScLaserRENRhoNDotPtr, 
double  ScLaserRENRhoRDotDotPtr , 
double  ScLaserRENRhoEDotDotPtr , 
double  ScLaserRENRhoNDotDotPtr , 

ErrorStructure  ScErrorList)  ; 


#endif 
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C.4  The  Target  Satellite  Library 


The  Target  Satellite  Library  houses  the  code  that  locates  the  satellite  and  its 
parameters  of  motion  with  the  help  of  an  interface  to  SGP4.  The  module  responsible  for 
accomplishing  this  task  is  Targets  atellite.  this  module  can  be  run  independently,  if 
desired,  using  the  GUI  shown  in  Figure  C.5.  This  GUI  is  run  using  the  C-H-  Builder 
module.  Targets  atelliteForm,  the  listing  for  which  can  be  seen  in  Appendix  E. 


Figure  C.5.  Graphical  Interface  for  TargetSateliite 
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C.4.1  TargetSatellite 


The  Target  Satellite  module  must  handle  three  functions.  First,  it  must  interface 
with  SGP4  (via  the  SGP4  Support  modules)  and  obtain  a  satellite’s  position  and  velocity 
as  of  the  Julian  Date  given,  in  the  ECI  frame.  Second,  based  on  the  position  of  the 
satellite  in  the  ECI  frame,  the  acceleration  of  the  satellite  in  the  ECI  frame  must  also  be 
calculated.  Third,  TargetSatellite  must  take  the  ECI-to-REN  conversion  matrix 
formulated  by  TargetPlatform,  and  convert  the  satellite  position,  velocity  and 
accelerations  in  the  ECI  frame  to  the  appropriate  vectors  in  the  REN  frame. 

Inputs 


struct  Satellite  &Sat  The  structure  holding  all  of  the  satellite 
ephemeris  information.  The  Type  “Satellite”  is  defined  in  Satellite.h. 

double  ThetaGInRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  &ECItoRENMatrixll  This  an  element  (row  1,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrlxl2  This  an  element  (row  1,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrixl3  This  an  element  (row  1,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix21  This  an  element  (row  2,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix22  This  an  element  (row  2,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix23  This  an  element  (row  2,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix31  This  an  element  (row  3,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 
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double  &ECItoRENMatrix32  This  an  element  (row  3,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix33  This  an  element  (row  3,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 


Outputs 

double  &SatECIRhoX  The  current  ECI  X  position  vector  of  the  position  of 
the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  SGP4. 

double  &SatECIRhoY  The  current  ECI  Y  position  vector  of  the  position  of 
the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  SGP4. 

double  &SatECIRhoZ  The  current  ECI  Z  position  vector  of  the  position  of 
the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  SGP4. 

double  &SatECIRhoXDot  The  current  ECI  X  velocity  vector  of  the 
velocity  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from 
SGP4. 

double  &SatECIRhoYDot  The  current  ECI  Y  velocity  vector  of  the 
velocity  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from 
SGP4. 

double  &SatECIRhoZDot  The  current  ECI  Z  velocity  vector  of  the 
velocity  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from 
SGP4. 

double  &SatECIRhoXDotDot  The  current  ECI  X  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  position  of  the  satellite  found  by  SGP4. 

double  &SatECIRhoYDotDot  The  current  ECI  Y  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  position  of  the  satellite  found  by  SGP4. 

double  &SatEClRhoZDotDot  The  current  ECI  Z  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  position  of  the  satellite  found  by  SGP4. 
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double  &SatRENRhoR  The  current  REN  R  (Radial)  position  vector  of  the 
position  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
ECI  position  vector,  found  by  SGP4,  rotated  into  the  REN  frame. 

double  &SatRENRhoE  The  current  REN  E  (East)  position  vector  of  the 
position  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
ECI  position  vector,  found  by  SGP4,  rotated  into  the  REN  frame. 

double  &SatRENRhoN  The  current  REN  N  (North)  position  vector  of  the 
position  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
ECI  position  vector,  found  by  SGP4,  rotated  into  the  REN  frame. 

double  &SatRENRhoRDot  The  current  REN  R  (Radial)  velocity  vector  of 
the  velocity  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame. 

double  &SatRENRhoEDot  The  current  REN  E  (East)  velocity  vector  of  the 
velocity  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame. 

double  &SatRENRhoNDot  The  current  REN  N  (North)  velocity  vector  of 
the  velocity  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame. 

double  &SatRENRhoRDotDot  The  current  REN  R  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  acceleration  in  the  ECI  frame. 

double  &SatRENRhoEDotDot  The  current  REN  E  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  acceleration  in  the  ECI  frame. 

double  &SatRENRhoNDotDot  The  current  REN  N  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  acceleration  in  the  ECI  frame. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 
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C.4.2  The  TargetSatellite.h  Header  File 


tifndef  TargetSatelliteH 
#define  TargetSatelliteH 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


MODULE  NAME: 
AUTHOR : 

DATE  CREATED: 

PURPOSE : 


COMPILER: 


TargetSatellite . cpp 
Captain  David  Vloedman 
November  17,  1998 


*/ 
*/ 
*/ 
*/ 

This  set  of  modules  supports  the  preprocessor  and  are^  */ 
used  to  establish  the  satellites  position,  velocity,  and*/ 
acceleration  wrt  the  platform  in  the  REN  frame.  */ 

*/ 
*/ 
*/ 


Borland  C++  BuilderS  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


/★*★***★★*★***★*★*****★*★***★***★*★*******★****★★****************************/ 

/*******★***★****************★***★/ 

/*  C++BUILDER-SPECIFIC  LIBRARIES  */ 

/**********★*★********************/ 

# include  <vcl.h> 

#pragma  hdrstop 

#pr agma  package ( smar t_ini t ) 

/******************★★**★****★*****/ 

/*  USER-BUILT  LIBRARIES  */ 

/*******************★★★**********★/ 
tinclude  "TimeModules .h” 

# include  "TLEInput.h" 

#include  "LaserConstants .h" 

#include  " Satellite .h" 

# include  "Aircraft.h" 

# include  " Error S true ture.h" 

# include  "EvaluateEphemerisModules . h” 

# include  " SGP4SupportModules .h" 
tinclude  "TargetSatellite.h” 

/*****★****★**********★*****★*****/ 

/*  C  STANDARD  LIBRARIES  */ 

/★********★*★*****★***★*****★*★***/ 

#include  <stdio.h> 
tinclude  <stdlib.h> 

#include  <string.h> 

#include  <iostream.h> 
iinclude  <conio.h> 

# include  <math.h> 


/* 

n 

n 

n 

1-* 

/* 

/* 

/* 

/" 

/* 


FUNCTION  NAME: 
AUTHOR: 

DATE  CREATED: 

PURPOSE : 


INPUTS : 


TargetSatellite 
Captain  David  Vloedman 
November  17,  1998 


*/ 
*/ 
*/ 
*/ 

This  function  will  take  the  position  of  the  aircraft  and*/ 
the  orbital  elements  of  the  satellite  and  calculate  */ 

the  azimuth  and  elevation  of  the  satellite  from  the  */ 

Airborn  laser  platform.  */ 

*/ 

NAME:  DEFINITION:  */ 

Sat  Holds  all  ephemeris  information  */ 

for  the  Satellite  being  studied  */ 
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/* 

/* 

/* 

/* 

/* 

/* 

/*  OUTPUTS: 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


JulianDate 

EC I t oRENMa t r ix ( RowC o 1 ) 

NAME: 

SatECIRhoX 

SatECIRhoY 

SatECIRhoZ 

SatECIRhoXDot 

SatECIRhoYDot 

SatECIRhoZDot 

SatECIRhoXDotDot 

SatECIRhoYDotDot 

SatECIRhoZDotDot 

SatRENRhoR 

SatRENRhoE 

SatRENRhoN 

SatRENRhoRDot 

SatRENRhoEDot 

SatRENRhoNDot 

SatRENRhoRDotDot 

Sa  t RENRhoEDo  t Do  t 


The  time  to  which  the  position  */ 
of  sat  should  be  propagated  to  */ 
The  ECI  to  REN  conversion  matrix*/ 
THIS  IS  USED  TO  CONVERT  FROM  ECI*/ 
COORDINATE  FRAME  TO  THE  RADIAL,  */ 
EAST,  NORTH  (REN)  FRAME.  */ 
DESCRIPTION:  */ 
X  magnitude  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  the  */ 
platform  radial  position  vector  */ 

Y  magnitude  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  the  */ 
platform  radial  position  vector  */ 
Z  magnitude  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  the  */ 
platform  radial  position  vector  */ 
X  velocity  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  vel  */ 
in  X  axis  direction.  */ 

Y  velocity  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  vel  */ 
in  Y  axis  direction.  */ 
Z  velocity  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  vel  */ 
in  Z  axis  direction.  */ 
X  accel.  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  acc.*/ 
in  X  axis  direction.  */ 

Y  accel.  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  ~  acc.*/ 
in  Y  axis  direction.  */ 
Z  accel.  in  ECI  frame  at  Jul  */ 
date  of  sat  radial  vector  -  acc.*/ 
in  Z  axis  direction.  */ 
The  Radial  Component  of  the  */ 
position  vector  of  the  satellite*/ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame.  */ 
The  East  Component  of  the  */ 
position  vector  of  the  satellite*/ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame.  */ 
The  North  Component  of  the  */ 
position  vector  of  the  satellite*/ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame.  */ 
The  Radial  Component  of  the  */ 
velocity  vector  of  the  satellite*/ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame .  * / 
The  East  Component  of  the  */ 
velocity  vector  of  the  satellite*/ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame.  */ 
The  North  Component  of  the  */ 
velocity  vector  of  the  satellite*/ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame .  * / 
The  Radial  Component  of  the  */ 
accel  vector  of  the  satellite  */ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame .  * / 
The  East  Component  of  the  */ 
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/* 

/* 

/* 

/ *  SatRENRhoNDotDot 

/* 

/* 

/* 

/*  ErrorList 


accel  vector  of  the  satellite  */ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame.  */ 
The  North  Component  of  the  */ 
accel  vector  of  the  satellite  */ 
wrt  Earth  center  in  the  REN  */ 
coordinate  frame.  */ 


The  Errors  which  have  occurred  */ 


/*  */ 

/*  COMPILER:  Borland  C++  Builder3  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 


/***★************★*★★********★*****************************★*********★*******/ 
void  TargetSatellite (struct  Satellite  &Sat, 

double  JulianDate, 


double  EGItoRENMatrixll , 
double  ECItoRENMatrixl2, 
double  ECItoRENMatrixl3 , 
double  ECItoRENMatrix21, 
double  ECItoRENMatrix22 , 
double  ECItoRENMatrix23, 
double  ECItoRENMatrix31, 
double  ECItoRENMatrix32, 
double  ECItoRENMatrix33, 
double  ScSatECIRhoX, 
double  &SatECIRhoY, 
double  &SatECIRhoZ, 
double  ScSatECIRhoXDot, 
double  &SatECIRhoYDot, 
double  &SatECIRhoZDot , 
double  &SatECIRhoXDotDot , 
double  &SatECIRhoYDotDot, 
double  ficSatECIRhoZDotDot , 
double  StSatRENRhoR, 
double  ScSatRENRhoE, 
double  &SatRENRhoN, 
double  &SatRENRhoRDot, 
double  ScSatRENRhoEDot, 
double  &SatRENRhoNDot , 
double  &SatRENRhoRDotDot, 
double  ScSatRENRhoEDotDot, 
double  &SatRENRhoNDotDot, 
ErrorStructure  ScErrorList)  ; 


#endif 
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C.5  The  Find  Displacement  Angle  Modules  Library 

The  modules  of  the  Find  Displacement  Angle  Modules  Library  are  responsible  for 
finding  the  angle  that  separates  the  laser  turret  unit  direction  position  vector  and  the 
satellite  position  vector.  This  includes  finding  the  separation  angle  of  these  two  vectors 
(as  seen  from  the  platform),  finding  the  rate  of  change  of  this  separation  angle,  and 
finding  the  acceleration  of  this  angle.  This  library  also  finds  the  error  angle  contributed 
by  position  errors  in  the  forecast.  The  three  modules  contained  in  this  library  are 
FindDisplacementAngles,  FindErrorAngle,  and  FindSeparationAngle.  These  three 
modules  can  be  tested  using  the  GUI  seen  in  Figure  C.6. 


Figure  C.6.  GUI  Used  to  Run  and  Test  FindDisplacementAngles  Module 
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C.5.1  FindDisplacementAngles 


FindDispacementAngles  is  the  primary  Module  in  this  library.  It  calls  bot 
FindErrorAngle  and  FindSeparationAngle.  It  also  calls  each  of  the  libraries  already 
discussed.  This  module  first  locates  the  laser  turret,  the  platform,  and  the  satellite  in  REN 
space  (using  the  libraries  above).  It  then  subtracts  the  platform  position,  velocity  and 
acceleration  from  the  satellite’s  position,  velocity  and  acceleration  to  locate  the  platform 
at  the  origin  of  the  REN  coordinate  frame  with  respect  to  the  satellite.  This  sets  up  the 
laser  turret  motion  vectors  and  the  satellite  motion  vectors  in  the  REN  frame  with  respect 
to  the  platform,  and  allows  the  separation  angle  to  be  found  more  easily.  A  call  to 
FindSeparationAngle  finds  the  separation  angle,  the  rate  of  change  of  the  angle  and  the 
acceleration  of  the  angle  betweent  the  laser  unit  position  vector  and  the  satellite  position 
vector.  A  call  is  also  made  to  FindErrorAngle  to  find  the  half-error  angle  resulting  from 
position  uncertainties  in  the  satellite,  platform,  and  missile. 

Inputs 


struct  Satellite  &Sat  The  structure  holding  all  of  the  satellite 
ephemeris  information.  The  Type  “Satellite”  is  defined  in  Satellite.h. 

struct  Aircraft  &ABLPlatfona  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  ThetaGInRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  JulianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 

double  AzimuthInDegrees  The  current  azimuth  of  the  laser  turret  in 
degrees. 
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double  ElevationInDegrees  The  current  elevation  of  the  laser  turret  in 
degrees. 

double  AzimuthDot  The  current  rate  of  change  of  the  azimuth  of  the  laser 
turret  in  degrees  per  second. 

double  ElevationDot  The  current  rate  of  change  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  AzimuthDot  Dot  The  current  acceleration  of  the  azimuth  of  the 
laser  turret  in  degrees  per  second. 

double  ElevationDot  Dot  The  current  acceleration  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  SatPositionErrorInMeters  The  radius  of  the  “sphere”  inside 
which  the  satellite  is  known  to  reside  (in  meters)  throughout  the  forecast  period 
(around  10  to  30  seconds).  For  SGP4,  this  may  be  as  high  as  around  10  km 
(10000  m). 

double  PlatformPositionErrorInMeters  The  radius  of  the  “sphere” 
inside  which  the  platform  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  For  a  747  on  autopilot  with  GPS  tracking,  a 
rough  estimate  might  be  50  meters. 

double  MissilePositionErrorlnMeters  The  radius  of  the  “sphere” 
inside  which  the  missile  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  This  may  just  be  an  educated  guess.  It  is 
difficult  to  now  the  behavior  of  the  missile  based  on  initial  conditions,  and  this 
parameter  will  have  to  be  given  some  thought. 

double  RangeToMissileInKilometers  The  range  from  the  platform  to 
the  missile. 

double  OtherErrorAngleInDeg  This  is  a  “catch-all”  parameter,  to  be 
used  if,  in  the  future,  there  are  other  error  angles  that  crop  up  that  have  not  already 
been  accounted  for. 

Outputs 

double  &PlatformSatRENKhoR  The  current  REN  R  (Radial)  position 
vector  of  the  position  of  the  satellite  with  respect  to  the  platform,  as  derived  from 
the  ECI  position  vector,  found  by  SGP4,  rotated  into  the  REN  frame,  and 
subtracted  by  the  platform  REN  position  vector. 
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double  &PlatfonaSatREIlIlhoE  The  current  REN  E  (East)  position 
vector  of  the  position  of  the  satellite  with  respect  to  the  platform,  as  derived  from 
the  ECI  position  vector,  found  by  SGP4,  rotated  into  the  REN  frame,  and 
subtracted  by  the  platform  REN  position  vector. 

double  &Plat£onnSatRENIlhoN  The  current  REN  N  (North)  position 
vector  of  the  position  of  the  satellite  with  respect  to  the  platform,  as  derived  from 
the  ECI  position  vector,  found  by  SGP4,  rotated  into  the  REN  frame,  and 
subtracted  bythe  platform  REN  position  vector. 

double  APlatformSatRENRhoRDot  The  current  REN  R  (Radial) 

velocity  vector  of  the  velocity  of  the  satellite  with  respect  to  the  platform,  as 
derived  from  the  ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame 
and  subtracted  by  the  platform  REN  velocity  vector 

double  &Plat£onaSatRENRhoEDot  The  current  REN  E  (East)  velocity 
velocity  vector  of  the  velocity  of  the  satellite  with  respect  to  the  platform,  as 
derived  from  the  ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame 
and  subtracted  by  the  platform  REN  velocity  vector 

double  &Plat£onnSatRENRhoNDot  The  current  REN  N  (North) 

velocity  vector  of  the  velocity  of  the  satellite  with  respect  to  the  platform,  as 
derived  from  the  ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame 
and  subtracted  by  the  platform  REN  velocity  vector 

double  &Plat£onnSatRENRboRDotDot  The  current  REN  R 

acceleration  vector  of  the  acceleration  of  the  satellite  with  respect  to  the  platform, 
as  derived  from  the  acceleration  in  the  ECI  frame,  rotated  into  the  REN  frame, 
subtracted  by  the  platform  REN  acceleration 

double  &Plat£oniiSatRENRhoEDotDot  The  current  REN  E 

acceleration  vector  of  the  acceleration  of  the  satellite  with  respect  to  the  platform, 
as  derived  from  the  acceleration  in  the  ECI  frame,  rotated  into  the  REN  frame, 
subtracted  by  the  platform  REN  acceleration 

double  &Plat£o2:mSatRENRboNDotDot  The  current  REN  N 

acceleration  vector  of  the  acceleration  of  the  satellite  with  respect  to  the  platform, 
as  derived  from  the  acceleration  in  the  ECI  frame,  rotated  into  the  REN  frame, 
subtracted  by  the  platform  REN  acceleration 

double  &LaserRENRhoR  The  current  REN  R  (Radial)  unit  position  vector 
of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation. 
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doxible  &LaserRENRhoE  The  current  REN  E  (East)  unit  position  vector  of 
the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth 
and  elevation. 

double  &LaserRENRhoN  The  current  REN  N  (North)  unit  position  vector 
of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation 

double  &LaserRENRhoRDot  The  current  REN  R  (Radial)  velocity  vector 
of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  jcLaserRENRhoEDot  The  current  REN  E  (East)  velocity  vector  of 
the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth, 
elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoNDot  The  current  REN  N  (North)  velocity  vector 
of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoRDotDot  The  current  REN  R  (Radial) 
acceleration  vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as 
derived  from  the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and 
elevation,  and  the  acceleration  of  the  azimuth  and  elevation. 

double  &LaserRENRhoEDotDot  The  current  REN  E  (East)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  &LaserRENIlhoI]DotDot  The  current  REN  N  (North)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  &RangeToSatI]iKilometers  Range  to  the  satellite  from  the 
platform  in  kilometers. 

double  &ErrorAngleInRadians  The  final  error  angle  (in  radians) 
resulting  from  the  position  errors  given  previously. 

double  &SeparatlonAngle  The  separation  angle  between  the  laser  turret 
unit  position  vector  and  the  satellite  position  vector  in  the  REN  frame. 

double  &SepAngleDot  The  rate  of  change  of  the  separation  angle  in  radians 
per  second. 
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double  &SepAngleDotDot  The  acceleration  of  the  separation  angle  in 
radians  per  second  squared. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 


C.5.2  FindErrorAngle 

The  module,  FindErrorAngle  is  the  module  responsible  for  taking  the  position 
uncertainty  errors  for  the  platform,  missile,  and  satellite,  along  with  the  ranges  to  the 
missile  and  satellite,  and  finding  the  error  angle  imposed  by  each  uncertainty.  It  then 
takes  the  sum  of  the  squares  of  each  of  these  error  angles  to  find  the  resulting  overall 
error  angle. 

Inputs 


double  &RangeToSatInKilometers  Range  to  the  satellite  from  the 
platform  in  kilometers. 

double  SatPositlonErrorInMeters  The  radius  of  the  “sphere”  inside 
which  the  satellite  is  known  to  reside  (in  meters)  throughout  the  forecast  period 
(around  10  to  30  seconds).  For  SGP4,  this  may  be  as  high  as  around  10  km 
(10000  m). 

double  PlatformPositionErrorXnMeters  The  radius  of  the  “sphere” 
inside  which  the  platform  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  For  a  747  on  autopilot  with  GPS  tracking,  a 
rough  estimate  might  be  50  meters. 

double  HissilePositionErrorInMeters  The  radius  of  the  “sphere” 
inside  which  the  missile  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  This  may  just  be  an  educated  guess.  It  is 
difficult  to  now  the  behavior  of  the  missile  based  on  initial  conditions,  and  this 
parameter  will  have  to  be  given  some  thought. 

double  RangeToMisslleZnKilometers  The  range  from  the  platform  to 
the  missile. 
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double  OtherErrorAnglelnDeg  This  is  a  “catch-all”  parameter,  to  be 
used  if,  in  the  future,  there  are  other  error  angles  that  crop  up  that  have  not  already 
been  accounted  for. 

Outputs 

double  &ErrorAngleInRadians  The  final  error  angle  (in  radians) 
resulting  from  the  position  errors  given  previously. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure  that 
is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list  any 
errors  occurring  in  this  module). 


C.5.3  FindSeparationAngle 

FindSeparationAngle  is  the  module  responsible  for  actually  calculating  the  angle 
between  the  unit  position  vector  for  the  laser  turret  and  the  position  vector  of  the  satellite 
(from  the  platform)  in  the  REN  frame.  It  is  also  responsible  for  finding  the  rate  of  change 
and  the  acceleration  of  the  change  of  this  separation  angle. 

Inputs 


double  LaserRENRhoR  The  current  REN  R  (Radial)  unit  position  vector 
of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation. 

double  LaserRENRhoE  The  current  REN  E  (East)  unit  position  vector  of 
the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth 
and  elevation. 

double  LaserRENRhoN  The  current  REN  N  (North)  unit  position  vector  of 
the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth 
and  elevation 

double  LaserRENRhoRDot  The  current  REN  R  (Radial)  velocity  vector 
of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  LaserRENRhoEDot  The  current  REN  E  (East)  velocity  vector  of 
the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth, 
elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 


double  LaserRENRhoNDot  The  current  REN  N  (North)  velocity  vector  of 
the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth, 
elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  LaserRENRhoRDotDot  The  current  REN  R  (Radial)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  LaserRENRhoEDotDot  The  current  REN  E  (East)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  LaserRENRhoNDotDot  The  current  REN  N  (North)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  SatRENRhoR  The  current  REN  R  (Radial)  position  vector  of  the 
position  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the  ECI 
position  vector,  found  by  SGP4,  rotated  into  the  REN  frame,  and  subtracted  by 
the  platform  REN  position  vector. 

double  SatRENRhoE  The  current  REN  E  (East)  position  vector  of  the 
position  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the  ECI 
position  vector,  found  by  SGP4,  rotated  into  the  REN  frame,  and  subtracted  by 
the  platform  REN  position  vector. 

double  SatRENRhoN  The  current  REN  N  (North)  position  vector  of  the 
position  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the  ECI 
position  vector,  found  by  SGP4,  rotated  into  the  REN  frame,  and  subtracted  bythe 
platform  REN  position  vector. 

double  SatRENRhoRDot  The  current  REN  R  (Radial)  velocity  vector  of 
the  velocity  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the  ECI 
velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame  and  subtracted  by  the 
platform  REN  velocity  vector 

double  SatRENRhoEDot  The  current  REN  E  (East)  velocity  velocity 
vector  of  the  velocity  of  the  satellite  with  respect  to  the  platform,  as  derived  from 
the  ECI  velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame  and 
subtracted  by  the  platform  REN  velocity  vector 

double  SatRENRhoNDot  The  current  REN  N  (North)  velocity  vector  of 
the  veloeity  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the  ECI 
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velocity  vector,  found  by  SGP4,  rotated  into  the  REN  frame  and  subtracted  by  the 
platform  REN  velocity  vector 

double  SatRENRhoRDotDot  The  current  REN  R  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the 
acceleration  in  the  ECI  frame,  rotated  into  the  REN  frame,  subtracted  by  the 
platform  REN  acceleration 

double  SatRENRhoEDotDot  The  current  REN  E  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the 
acceleration  in  the  ECI  frame,  rotated  into  the  REN  frame,  subtracted  by  the 
platform  REN  acceleration 

double  SatRENRhoNDotDot  The  current  REN  N  acceleration  vector  of 
the  acceleration  of  the  satellite  with  respect  to  the  platform,  as  derived  from  the 
acceleration  in  the  ECI  frame,  rotated  into  the  REN  frame,  subtracted  by  the 
platform  REN  acceleration 

Outputs 

double  &SeparatlonAngle  The  separation  angle  between  the  laser  turret 
unit  position  vector  and  the  satellite  position  vector  in  the  REN  frame. 

double  &SepAngleDot  The  rate  of  change  of  the  separation  angle  in  radians 
per  second. 

double  &SepAiigleDotDot  The  acceleration  of  the  separation  angle  in 
radians  per  second  squared. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 
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C.5.4  The  FindDisplacenientAngleModules.h  Header  File 


# i f nde f  FindDi sp lac emen t Ang 1 eModu 1 e sH 
#define  FindDi splacementAngleModulesH 

/******************  ^r***** ******************************************* **★**★*★*/ 

/*  MODULE  NAME:  FindDi sp lacementAngleModules . h  */ 

/*  AUTHOR:  Captain  David  Vloedman  */ 

/*  DATE  CREATED:  3  January,  1999  */ 

/*  */ 

/*  PURPOSE:  This  set  of  modules  supports  the  Main  Processor  and  are  */ 

/*  used  to  evaluate  the  error  angle  and  the  displacement  */ 

/*  angle  between  the  laser  position  vector  in  the  REN  frame*/ 

/*  and  the  satellite  position  vector  in  the  same  frame.  */ 

/*  */ 

/*  COMPILER:  Borland  C++  Builder 3  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 


/**********************Tif  *  ******************************  **•***★★*★**  ★*★*★★★****/ 

/*************************★*★*★★**/ 

/*  C++BUILDER-SPECIFIC  LIBRARIES  */ 

/*********************************/ 

# include  <vcl.h> 

#pragma  hdrstop 

#pragma  package ( smar t_ini t ) 

/******★********★*★*****★**★*★****/ 

/*  USER-BUILT  LIBRARIES  */ 

/****************************★*★**/ 

#include  "TimeModules .h" 

# include  "TLEInput.h" 

# include  "LaserConstants .h” 

#include  "Satellite .h" 

#include  "Aircraft.h" 

# include  "ErrorStructure .h" 

# include  "EvaluateEphemerisModules .h" 

# include  "SGP4SupportModules .h" 

#include  "TargetSatellite . h" 

#include  "TargetPlatform.h" 
tinclude  "TargetLaser . h" 

/***★************************★**★*/ 

/*  C  STANDARD  LIBRARIES  */ 

/*★****★****★******★****★*********/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <string.h> 

#include  <iostream.h> 

#include  <conio.h> 

# include  <math.h> 


/*  FUNCTION  NAME:  FindDisplacementAngles  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  January  3,  1999  */ 
/*  */ 


/*  PURPOSE:  This  function  will  take  satellite  and  platform  data  and  */ 
/*  willuse  it  to  find  the  error  angle  and  the  displacement  */ 
/*  angle  between  the  laser  position  vector  in  the  REN  frame*/ 
/*  and  the  satellite  position  vector  in  the  same  frame.  */ 
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/* 

/ *  INPUTS : 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

•/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/*  OUTPUTS: 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


*/ 

NAME:  DEFINITION:  */ 

Sat  Holds  all  ephemeris  information  */ 

for  the  Satellite  being  studied  */ 
ABLPlatform  Holds  all  information  about  ABL  */ 

Platform  position/disposition  */ 
JulianDate  The  time  to  which  the  position  */ 

of  sat  should  be  propagated  to  */ 
ThetaGInRadians  The  angle  between  the  Greenwich  */ 

Meridian  and  the  Vernal  Equinox  */ 


at  JulianDate.  */ 

LazerAzimuthInDegrees  Lazer  Azimuth  at  Laze  Start  time*/ 

in  Degrees  ^  */ 

LazerAzimuthDot  The  rate  of  change  of  the  Az  */ 

in  Degrees /Sec.  */ 

LazerAzimuthDotDot  The  rate  of  change  of  the  rate  */ 

of  change  of  the  Azimuth  (Accel)*/ 
in  Degrees /Sec'^2  */ 

LazerElevationInDegrees  Lazer  Elevation  at  Laze  Start  */ 

in  Degrees  */ 

LazerElevationDot  The  rate  of  change  of  the  El  */ 

in  Degrees /Sec.  */ 

LazerElevationDotDot  The  rate  of  change  of  the  rate  */ 

of  change  of  the  Elevat.  (Accel)*/ 
in  Degrees/Sec^2  */ 

SatPositionErrorInMeters  Holds  the  radius  of  the  error  */ 

spheroid  that  describes  the  */ 

area  in  which  the  satellite  is  */ 
known  to  exist  (in  meters) .  */ 

PlatformPositionError .. .Holds  the  radius  of  the  error  */ 

spheroid  that  describes  the  */ 

area  in  which  the  platform  is  */ 
known  to  exist  (in  meters) .  */ 

MissilePositionError . . .  Holds  the  radius  of  the  error  */ 

spheroid  that  describes  the  */ 

area  in  which  the  missile  is  */ 
known  to  exist  (in  meters) .  */ 

RangeToMissileInKilo . . .  The  Range  to  the  missile  (km)  */ 

OtherErrorAnglesInDeg  Holds  any  other  error  angles  */ 

(in  degrees)  that  may  be  a  */ 

significant  source  of  error.  */ 

This  should  usually  be  set  to  */ 
zero  (0.0)  float.  */ 

NAME:  DESCRIPTION:  */ 

PlatformSatRENRhoR  The  Radial  Component  of  the  */ 

position  vector  of  the  satellite*/ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

Plat forms at RENRhoE  The  East  Component  of  the  */ 

position  vector  of  the  satellite*/ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

Platf ormSatRENRhoN  The  North  Component  of  the  */ 

position  vector  of  the  satellite*/ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

PlatformSatRENRhoRDot  The  Radial  Component  of  the  */ 

velocity  vector  of  the  satellite*/ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

Platf ormSatRENRhoEDot  The  East  Component  of  the  */ 

velocity  vector  of  the  satellite*/ 
wrt  the  platform  in  the  REN  */ 
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/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


Plat  forms  a  t RENRhoNDo  t 


coordinate  frame.  */ 

The  North  Component  of  the  */ 

velocity  vector  of  the  satellite*/ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

PlatformSatRENRhoRDotDot  The  Radial  Component  of  the  */ 

accel  vector  of  the  satellite  */ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

PlatformSatRENRhoEDotDot  The  East  Component  of  the  */ 

accel  vector  of  the  satellite  */ 
wrt  the  platform  in  the  REN  */ 
coordinate  frame.  */ 

PlatformSatRENRhoNDotDot  The  North  Component  of  the  */ 

accel  vector  of  the  satellite  */ 
wrt  the  platform  in  the  REN  */ 

coordinate  frame.  */ 

The  Radial  unit  direction  of  the*/ 
lazer  beam  trajectory  in  the  REN*/ 
frame .  * / 

The  East  unit  direction  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame.  */ 

The  North  unit  direction  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame.  */' 

The  Radial  unit  velocity  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dirXradians/sec  */ 
The  East  unit  velocity  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dirXradians/sec  */ 
The  North  unit  velocity  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dirXradians/sec  */ 
The  Radial  unit  accel.  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dirXradians/sec^2  */ 
The  East  unit  accel.  of  the  */ 

lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dirXradians/sec^2  */ 
The  North  unit  accel.  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dirXradians/sec^2  */ 
Holds  the  range  of  the  aircraft  */ 
to  the  satellite  in  kilometers.  */ 
The  total  error  angle  in  radians*/ 
The  separation  (in  radians)  of  */ 
the  LaserRENRho  and  */ 

PlatformSatRENRho  vectors.  */ 

The  rate  of  change  (in  rad/ sec)  */ 
of  the  separation  of  LaserRENRho*/ 
PlatformSatRENRho  vectors.  */ 

The  acceleration  (in  rad/sec'^2)  */ 
of  the  separation  of  LaserRENRho*/ 


LaserRENRhoR 


LaserRENRhoE 


Las  er RENRhoN 


LaserRENRhoRDot 


LaserRENRhoEDot 


Las  er RENRhoNDo  t 


LaserRENRhoRDotDot 


Las  er RENRhoEDo  tDo  t 


Las  erRENRhoNDo  tDo  t 


RangeInKilometers 

ErrorAngleInRadians 

SeparationAngle 


SeparationAngleDot 


SeparationAngleDotDot 


ErrorList 


and  PlatformSatRENRho  vectors. 
The  Errors  which  have  occurred 


COMPILER:  Borland  C++  BuilderS  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


/*  */ 

/*********************★**★**★***★*★*********************★********************/ 
void  FindDisplacementAngles (struct  Aircraft  &Platform, 
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struct  Satellite  &Sat, 

double  &ThetaGInRad, 

double  JulianDate, 

double  LaserAzimuthlnDegrees , 

double  LaserAzimuthDot , 

double  LaserAzimuthDotDot , 

double  LaserElevationInDegrees, 

double  LaserElevationDot , 

double  LaserElevationDotDot , 

double  SatPositionErrorInMeters , 

double  Platf ormPositionErrorlnMeters , 

double  MissilePositionErrorInMeters , 

double  RangeToMissilelnKilometers , 

double  OtherErrorAngleInDeg, 

double  &PlatfoniiSatRENRhoR, 

double  ScPlatformSatRENRhoE, 

double  &PlatformSatRENRhoN, 

double  &PlatforinSatRENRhoRDot , 

double  ScPlatformSatRENRhoEDot, 

double  ScPlatformSatRENRhoNDcit , 

double  &Platf ormSatRENRhoRDotDot, 

double  &PlatformSatRENRhoEDotDot , 

double  &PlatformSatRENRhoNDotDot , 

double  &LaserRENRhoR, 

double  &LaserRENRhoE, 

double  &LaserRENRhoN; 

double  &LaserRENRhoRDot ; 

double  &LaserRENRhoEDot , 

double  ScLaserRENRhoNDot , 

double  ScLaserRENRhoRDotDot , 

double  ScLaserRENRhoEDotDot , 

double  &iLaserRENRhoNDotDot , 

double  &RangeToSatInKilometers , 

double  &ErrorAngleInRadians, 

double  ScSeparationAngle, 

double  ScSepAngleDot, 

double  ScSepAngleDotDot , 

Errors true ture  &ErrorList) ; 


/* 

FUNCTION  NAME: 

FindErrorAngle 

*/ 

/* 

AUTHOR : 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

January  3,  1999 

*/ 

/* 

*/ 

/* 

PURPOSE: 

This  function  will  take 

the  range  to  satellite  and  the 

*/ 

/* 

satellite  position  error  and  fiond  the  appropriate  error*/ 

/* 

error  angle. 

*/ 

/* 

*/ 

/* 

INPUTS : 

NAME: 

DEFINITION: 

*/ 

/* 

Range 

Holds  the  range  of  the  aircraft 

*/ 

/* 

to  the  satellite  in  kilometers. 

*/ 

/* 

SatPositionErrorInMeters  Holds  the  radius  of  the  error 

*/ 

spheroid  that  describes  the 

*/ 

/* 

area  in  which  the  satellite  is 

*/ 

/* 

known  to  exist  (in  meters) . 

*/ 

/* 

Platf ormPositionError. . . 

Holds  the  radius  of  the  error 

*/ 

/* 

spheroid  that  describes  the 

*/ 

/* 

area  in  which  the  platform  is 

*/ 

/* 

known  to  exist  (in  meters) . 

*/ 

/* 

MissilePositionError . . . 

Holds  the  radius  of  the  error 

*/ 

/* 

spheroid  that  describes  the 

*/ 

/* 

area  in  which  the  missile  is 

*/ 
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/*  known  to  exist  (in  meters) .  */ 
/*  RangeToMissileInKilo . . .  The  Range  to  the  missile  (km)  */ 
/*  OtherErrorAnglesInDeg  Holds  any  other  error  angles  */ 
/*  (in  degrees)  that  may  be  a  */ 
/*  significant  source  of  error.  */ 
/*  This  should  usually  be  set  to  */ 
/*  zero  (0,0)  float.  */ 
/*  OUTPUTS:  NAME:  DESCRIPTION:  */ 
/*  ErrorAngleInRadians  The  total  error  angle  in  radians*/ 
/*  ErrorList  The  Errors  which  have  occurred  */ 
/★  */ 
/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/****************************************************************************^ 
void  FindErrorAngle (double  RangeToSatInKilometers , 

double  SatPositionErrorInMeters, 
double  Platf ormPositionErrorInMeters , 
double  MissilePositionErrorInMeters , 
double  RangeToMissileInKilometers , 
double  OtherErrorAnglesInDeg, 
double  &ErrorAngleInRadians, 

ErrorStructure  &ErrorList) ; 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


************ *************************************************^*************/ 
FUNCTION  NAME:  FindSeparationAngle  */ 

AUTHOR:  Captain  David  Vloedman  */ 

DATE  CREATED:  January  3,  1999  */ 

*/ 

PURPOSE:  This  routine  finds  the  angle  separating  the  satellite  */ 

position  vector  and  the  laser  turret  unit  direction  */ 

vector  in  the  REN  coordinate  frame,  as  well  as  the  rate  */ 
of  change  and  the  acceleration  of  that  separation.  */ 


INPUTS :  NAME : 

LaserRENRhoR 

LaserRENRhoE 

LaserRENRhoN 

LaserRENRhoRDot 

LaserRENRhoEDot 

LaserRENRhoNDot 

LaserRENRhoRDot Dot 

LaserRENRhoEDotDot 

LaserRENRhoNDotDot 


*/ 

DEFINITION:  */ 
The  Radial  unit  direction  of  the*/ 
lazer  beam  trajectory  in  the  REN*/ 
frame .  * / 
The  East  unit  direction  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame .  * / 
The  North  unit  direction  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame .  * / 
The  Radial  unit  velocity  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dir*radians/sec  */ 
The  East  unit  velocity  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dir*radians/sec  */ 
The  North  unit  velocity  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dir*radians/sec  */ 
The  Radial  unit  accel .  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dir*radians/sec^2  */ 
The  East  unit  accel.  of  the  */ 
lazer  beam  trajectory  in  the  REN*/ 
frame  in  unit  dir*radians/sec^2  */ 
The  North  unit  accel.  of  the  */ 
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/* 

lazer  beam  trajectory  in  the  REN*/ 

/* 

frame  in  unit  dir*radians/sec^2 

*/ 

/* 

SatRENRhoR 

The  Radial  Component  of  the 

*/ 

/* 

position  vector  of  the  satellite*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame. 

*/ 

/* 

SatRENRhoE 

The  East  Component  of  the 

*/ 

/* 

position  vector  of  the  satellite*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame. 

*/ 

/* 

SatRENRhoN 

The  North  Component  of  the 

*/ 

/* 

position  vector  of  the  satellite*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame. 

*/ 

/* 

SatRENRhoRDot 

The  Radial  Component  of  the 

*/ 

/* 

velocity  vector  of  the  satellite*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame . 

*/ 

/* 

SatRENRhoEDot 

The  East  Component  of  the 

*/ 

/* 

velocity  vector  of  the  satellite*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame . 

*/ 

/* 

SatRENRhoNDot 

The  North  Component  of  the 

*/ 

/* 

velocity  vector  of  the  satellite*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame . 

*/ 

/* 

Sa tRENRhoRDo  tDo  t 

The  Radial  Component  of  the 

*/ 

/* 

accel  vector  of  the  satellite 

*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame. 

*/ 

/* 

Sa tRENRhoEDo  tDo  t 

The  East  Component  of  the 

*/ 

/* 

accel  vector  of  the  satellite 

V 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame. 

*/ 

/* 

SatRENRhoNDotDot 

The  North  Component  of  the 

*/ 

/* 

accel  vector  of  the  satellite 

*/ 

/* 

wrt  the  platform  in  the  REN 

*/ 

/* 

coordinate  frame . 

*/ 

/* 

*/ 

/* 

OUTPUTS : 

NAME: 

DESCRIPTION: 

*/ 

/* 

SeparationAngle 

The  separation  (in  radians)  of 

*/ 

/* 

the  LaserRENRho  and 

*/ 

/* 

Platf ormSatRENRho  vectors. 

*/ 

/* 

SeparationAngleDot 

The  rate  of  change  (in  rad/ sec) 

*/ 

/* 

of  the  separation  of  LaserRENRho 

*/ 

/* 

Platf ormSatRENRho  vectors. 

*/ 

/* 

SeparationAngleDotDot 

The  acceleration  (in  rad/sec^2) 

*/ 

/* 

of  the  separation  of  LaserRENRho 

*/ 

/* 

and  Platf ormSatRENRho  vectors. 

*/ 

/* 

ErrorList 

The  Errors  which  have  occurred 

*/ 

/* 

*/ 

/* 

COMPILER: 

Borland  C++  BuilderS  Standard  version 

*/ 

/* 

This  compiler  should  be 

used  to  compile  and  link. 

*/ 

/* 

*/ 

/*****************************★*********************★**********★*************/ 

void  FindSeparationAngle (double  LaserRENRhoR, 

double  LaserRENRhoE; 
double  LaserRENRhoN, 
double  Las erRENRhoRDo t , 
double  LaserRENRhoEDot , 
double  LaserRENRhoNDot , 
double  Las erRENRhoRDo tDot; 
double  Las erRENRhoEDo tDot, 


double  LaserRENRhoNDotDot , 

double  SatRENRhoR, 

double  SatRENRhoE, 

double  SatRENRhoN, 

double  SatRENRhoRDot, 

double  SatRENRhoEDot, 

double  SatRENRhoNDot, 

double  SatRENRhoRDotDot , 

double  SatRENRhoEDotDot , 

double  SatRENRhoNDotDot, 

double  ScSeparationAnglelnRadians , 

double  &SepAngleDot, 

double  &SepAngleDotDot, 

ErrorStructure  &ErrorList) ; 

#endif 
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C.6  The  Process  Satellite  Library 


The  Process  Satellite  Library  holds  the  modules  responsible  for  tying  together  all 
of  the  modules  mentioned  previously  to  successfully  evaluate  a  single  satellite.  This 
library  is  composed  of  four  modules,  ProcessSatellite,  Interpolate  Vertex, 
FindDisplacementAngles Again,  and  TargetPlatformAgain.  ProcessSatellite  is  the  master 
module  that  uses  all  of  the  other  modules  to  complete  the  evaluation  of  a  single  satellite. 
Process  Satellite  can  be  run  independently  of  the  Main  Processor  by  using  a  calling 
program  such  as  the  GUI  used  in  this  project,  shown  in  Figure  C.7. 


C.6.1  ProcessSatellite 


As  mentioned  previously,  ProcessSatellite  is  one  of  the  master  modules  of  the 
Main  Processor.  It  is  responsible  for  tying  together  all  of  the  modules  discussed  so  far,  to 
process  and  evaluate  a  single  satellite.  It  first  calls  FindDisplacementAngles  to  find  a 
forecasted  intercept  time,  and  then,  if  the  satellite  is  forecasted  to  intersect  the  laser,  it 
calls  InterpolateVertex  to  more  closely  examine  that  lintersection  point. 

Inputs 


stzxict  Satellite  &Sat  The  structure  holding  all  of  the  satellite 
ephemeris  information.  The  Type  “Satellite”  is  defined  in  Satellite.h. 

struct  Aircraft  &ABLPlat£onti  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  JulianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 

double  AzimuthZnDegrees  The  current  azimuth  of  the  laser  turret  in 
degrees. 

double  ElevationInDegrees  The  current  elevation  of  the  laser  turret  in 
degrees. 

double  AzimuthDot  The  current  rate  of  change  of  the  azimuth  of  the  laser 
turret  in  degrees  per  second. 

double  ElevationDot  The  current  rate  of  change  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  AzimuthDotDot  The  current  acceleration  of  the  azimuth  of  the 
laser  turret  in  degrees  per  second. 

double  ElevationDotDot  The  current  acceleration  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  SatPositionErrorInMeters  The  radius  of  the  “sphere”  inside 
which  the  satellite  is  known  to  reside  (in  meters)  throughout  the  forecast  period 
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(around  10  to  30  seconds).  For  SGP4,  this  may  be  as  high  as  around  10  km 
(10000  m). 

double  PlatformPositionErrorlnMeters  The  radius  of  the  “sphere” 
inside  which  the  platform  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  For  a  747  on  autopilot  with  GPS  tracking,  a 
rough  estimate  might  be  50  meters. 

double  MissilePositionErrorlxiMeters  The  radius  of  the  “sphere” 
inside  which  the  missile  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  This  may  just  be  an  educated  guess.  It  is 
difficult  to  now  the  behavior  of  the  missile  based  on  initial  conditions,  and  this 
parameter  will  have  to  be  given  some  thought. 

double  RangeToMissilelnKilometers  The  range  from  the  platform  to 
the  missile. 

double  OtherErrorAziglelnDeg  This  is  a  “catch-all”  parameter,  to  be 
used  if,  in  the  future,  there  are  other  error  angles  that  crop  up  that  have  not  already 
been  accounted  for. 

int  ReferenceHour  Reference  hour  Refers  to  the  Reference  angle  of  0g 
(The  angle  between  the  Greenwich  meridian  and  the  Vernal  Equinox).  This 
angles  is  given  in  hours,  minutes  and  seconds  as  opposed  to  degrees  or  radians. 
This  parameter  holds  the  hours  portion  of  6g. 

int  ReferenceMinute  The  minutes  portion  of  6g. 

double  ReferenceSecond  The  seconds  portion  of  0g. 

double  RefModiJulianDate  This  parameter  holds  the  Modified  Julian 
Date  at  which  the  reference  angle,  0g,  was  taken.  This  allows  0g  to  be  propagated 
forward  to  the  present  moment. 

double  SecondsFromVertex  This  input  parameter  describes  the  number 
of  seconds  before  the  forecast  intercept  time  the  the  user  desires  to  analyze  via 
interpolation.  For  a  better  explanation  on  interpolation,  see  Chapter  III.  The 
author  recommends  this  time  interval  be  around  2.0  seconds. 

double  Interpolationlncrement  The  amount  of  time  that  transpires 
between  samplings  when  interpolating  the  vertex.  For  a  better  extplanation  on 
interpolation,  see  Chapter  III.  The  author  recommends  this  time  interval  be 
around  0.1  seconds. 
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double  LazeDuration  The  expected  amount  of  time  that  the  lazer  will  be 
“on”,  or  illuminating  its  target.  It  is  estimated  that  this  value  should  never 
operationally  exceed  thirty  seconds. 

Outputs 

double  ThetaGInRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  &RangeInKilometers  Range  to  the  satellite  from  the  platform 
in  kilometers. 

double  &ErrorAngleInRadians  The  final  error  angle  (in  radians) 
resulting  from  the  position  errors  given  previously. 

double  &SeparationAngle  The  separation  angle  between  the  laser  turret 
unit  position  vector  and  the  satellite  position  vector  in  the  REN  frame. 

double  &SepAngleDot  The  rate  of  change  of  the  separation  angle  in  radians 
per  second. 

double  &SepAngleDotDot  The  acceleration  of  the  separation  angle  in 
radians  per  second  squared. 

int  &Intersection  This  is  a  boolean  value  that  informs  the  user  as 
to  whether  an  intersection  has  been  determined  to  occur  or  not. 

0  =  No  intersection  determined 
1  =  Intersection  determined 

int  &Interpolation  This  is  a  boolean  parameter  that  tells  the  user 
whether  or  not  the  satellite  was  forecast  to  come  close  enough  to  the  laser  vector 
to  warrant  an  interpolation. 

0  =  Satellite  not  close  enough  to  warrant  interpolation. 

1  =  Satellite  approached  close  enough,  interpolation  performed. 

double  &TimeToIntersect  If  an  intersection  is  determined  to  occur,  this 
parameter  will  tell  how  many  seconds  into  the  future  this  intersection  will  occur. 
If  an  intersection  does  not  occur,  this  parameter  will  be  set  to  0.0. 

double  &ClosestApproachIiiDegrees  The  closest  that  this  satellite 
ever  comes  to  the  laser  position  vector. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 
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C.6.2  InterpolateVertex 


InterpolateVeitex  is  responsible  for  propagation  of  the  actual  positions  of  the 
different  players  of  the  satellite  analysis  in  time.  This  actual  propagation  is  used  to  find 
the  “real”  separation  angle  between  the  satellite  position  vector  and  the  laser  position 
vector  at  different  points  in  time.  Although  this  procedure  yields  a  fairly  exact  forecast 
for  the  separation  angle,  it  is  not  used  for  every  satellite,  because  it  is  calculation 
intensive.  Rather  ProcessSatellite  uses  a  rough  forecast  based  upon  the  initial  saparation 
angle,  the  rate  of  change,  and  the  acceleration  of  the  angle.  If  this  initial  forecast 
indicates  a  close-approach  (an  intersection,  according  to  the  forecast)  of  the  satellite,  then 
and  only  then  is  InterpolateVertex  called  to  fully  evaluate  that  close  approach.  Because 
many  of  the  calculations  needed  to  propagate  positions  in  time  have  already  been  done, 
InterpolateVertex  does  not  call  FindDisplacementAngles  or  TargetPlatform,  as  might 
normally  be  expected  when  trying  to  find  the  new  position  of  the  platform  and  the 
separation  angle.  Rather,  a  shortened  version  of  these  two  modules, 
FindDisplacementAnglesAgain,  and  TargetPlatformAgain,  were  created  to  lighten  the 
processing  load.  Further  examination  of  these  modules  will  reveal  that  even  more  can  be 
stripped  from  these  modules  to  further  condense  the  amount  of  processing  needed. 
Unfortunately,  there  was  not  enough  time  to  “optimize”  these  two  modules  and  perform 
the  necessary  testing  again,  as  of  the  writing  of  this  final  draft.  However,  it  should  not  be 
that  difficult  to  identify  the  portions  of  these  shortened  modules  that  are  not  needed  to 
find  only  the  separation  angle.  As  the  software  stands,  however,  it  is  still  running  within 
an  acceptable  time  margin.  InterpolateVertex  is  the  only  module  to  call 
FindDisplacementAnglesAgain  and  TargetPlatformAgain. 
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struct  Satellite  &Sat  The  structure  holding  all  of  the  satellite 
ephemeris  information.  The  Type  “Satellite”  is  defined  in  Satellite.h. 

struct  Aircraft  &ABLPlat£onn  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

int  ReferenceHour  Reference  hour  Refers  to  the  Reference  angle  of  0g 
(The  angle  between  the  Greenwich  meridian  and  the  Vernal  Equinox).  This 
angles  is  given  in  hours,  minutes  and  seconds  as  opposed  to  degrees  or  radians. 
This  parameter  holds  the  hours  portion  of  0g, 

int  ReferenceMinute  The  minutes  portion  of  0g. 

double  ReferenceSecond  The  seconds  portion  of  0g. 

double  RefModJulianDate  This  parameter  holds  the  Modified  Julian 
Date  at  which  the  reference  angle,  0g,  was  taken.  This  allows  0g  to  be  propagated 
forward  to  the  present  moment. 

double  LazeDuration  The  expected  amount  of  time  that  the  lazer  will  be 
“on”,  or  illuminating  its  target.  It  is  estimated  that  this  value  should  never 
operationally  exceed  thirty  seconds. 

double  JulianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 

double  AzimuthInDegrees  The  current  azimuth  of  the  laser  turret  in 
degrees. 

double  ElevationInDegrees  The  current  elevation  of  the  laser  turret  in 
degrees. 

double  AzimuthDot  The  current  rate  of  change  of  the  azimuth  of  the  laser 
turret  in  degrees  per  second. 

double  ElevationDot  The  current  rate  of  change  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  AzimuthDotDot  The  current  acceleration  of  the  azimuth  of  the 
laser  turret  in  degrees  per  second. 


double  ElevationDotDot  The  current  acceleration  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  ErrorAngleInRadians  The  final  error  angle  (in  radians) 
resulting  from  the  position  errors  given  previously. 

double  SecondsFromVertex  This  input  parameter  describes  the  number 
of  seconds  before  the  forecast  intercept  time  the  the  user  desires  to  analyze  via 
interpolation.  For  a  better  explanation  on  interpolation,  see  Chapter  HI.  The 
author  recommends  this  time  interval  be  around  2.0  seconds. 

double  Interpolationlncrement  The  amount  of  time  that  transpires 
between  samplings  when  interpolating  the  vertex.  For  a  better  extplanation  on 
interpolation,  see  Chapter  III.  The  author  recommends  this  time  interval  be 
around  0.1  seconds. 

Outputs 

double  &TimeToIiitersect  If  an  intersection  is  determined  to  occur,  this 
parameter  will  tell  how  many  seconds  into  the  future  this  intersection  will  occur. 
If  an  intersection  does  not  occur,  this  parameter  will  be  set  to  0.0. 

double  &ClosestApproachIiiDegrees  The  closest  that  this  satellite 
ever  comes  to  the  laser  position  vector. 

Err  or  Structure  &ErrorList  This  is  the  error-handling  structure 

that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 


C.6.3  FindDisplacementAnglesAgain 

FindDisplacementAnglesAgain  is  a  module  that  is  a  shortened  version  of  the 
original  FindDisplacementAngles  module  that  found  the  sepearation  angle,  as  well  as  the 
rate  of  change  and  acceleration  of  that  angle.  To  prevent  azimuth  and  elevation 
reconversion  to  ECI  coordinates,  three  new  parameters  were  added  to  simply  propagate 
the  platforms  motion  in  the  ECEF  frame.  Admittedly,  this  module  could  have  been  done 
more  thoughtfully.  Time  was  running  out,  and  a  quick  fix  was  needed  to  make 


184 


InterpolateVertex  run.  Further  optimization  efforts  should  start  here,  with  these  two 
modules. 

Inputs 


struct  Satellite  &Sat  The  structure  holding  all  of  the  satellite 
ephemeris  information.  The  Type  “Satellite”  is  defined  in  Satellite.h. 

struct  Aircraft  &ABLPlatfona  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  ThetaGIuRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  JulianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 

double  ChangeInX  This  is  the  ECEF  X  propagation  distance  used  to 
propagate  the  platform  position  forward  in  time. 

double  ChangelnY  This  is  the  ECEF  Y  propagation  distance  used  to 
propagate  the  platform  position  forward  in  time. 

double  Change  InZ  This  is  the  ECEF  Z  propagation  distance  used  to 
propagate  the  platform  position  forward  in  time. 

double  AzlmuthlnDegrees  The  current  azimuth  of  the  laser  turret  in 
degrees. 

double  ElevationInDegrees  The  current  elevation  of  the  laser  turret  in 
degrees. 

double  AzimuthDot  The  current  rate  of  change  of  the  azimuth  of  the  laser 
turret  in  degrees  per  second. 

double  ElevatlonSot  The  current  rate  of  change  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  AzimuthDot  Dot  The  current  acceleration  of  the  azimuth  of  the 
laser  turret  in  degrees  per  second. 
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double  ElevationDotDot  The  current  acceleration  of  the  elevation  of  the 
laser  turret  in  degrees  per  second. 

double  ErrorAnglelnRadians  The  final  error  angle  (in  radians) 
resulting  from  the  position  errors  given  previously.  In  the  Original 
FindDisplacementAngles,  this  was  an  output  parameter,  but  since  it  has  already 
been  found,  it  need  not  be  recalculated  for  the  Mef  forecast  time. 

Outputs 

double  &LaserRENRhoR  The  current  REN  R  (Radial)  unit  position  vector 
of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation. 

double  &LaserRENRboE  The  current  REN  E  (East)  unit  position  vector  of 
the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth 
and  elevation. 

double  &LaserRENBboN  The  current  REN  N  (North)  unit  position  vector 
of  the  position  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth  and  elevation 

double  ALaserRENRhoRDot  The  current  REN  R  (Radial)  velocity  vector 
of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoEDot  The  current  REN  E  (East)  velocity  vector  of 
the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the  azimuth, 
elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoNDot  The  current  REN  N  (North)  velocity  vector 
of  the  velocity  of  the  laser  with  respect  to  the  platform,  as  derived  from  the 
azimuth,  elevation  and  the  rate  of  change  of  the  azimuth  and  elevation. 

double  &LaserRENRhoRDotDot  The  current  REN  R  (Radial) 
acceleration  vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as 
derived  from  the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and 
elevation,  and  the  acceleration  of  the  azimuth  and  elevation. 

double  &LaserRENRhoEDotDot  The  current  REN  E  (East)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  &LaserRENRhoNDotDot  The  current  REN  N  (North)  acceleration 
vector  of  the  acceleration  of  the  laser  with  respect  to  the  platform,  as  derived  from 
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the  azimuth,  elevation,  the  rate  of  change  of  the  azimuth  and  elevation,  and  the 
acceleration  of  the  azimuth  and  elevation. 

double  &RangeToSatInKiloineters  Range  to  the  satellite  from  the 
platform  in  kilometers. 

double  &SeparationAngle  The  separation  angle  between  the  laser  turret 
unit  position  vector  and  the  satellite  position  vector  in  the  REN  frame. 

double  &SepAngleDot  The  rate  of  change  of  the  separation  angle  in  radians 
per  second. 

doxible  &SepAngleDotDot  The  acceleration  of  the  separation  angle  in 
radians  per  second  squared. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 


C.6.4  TargetPlatformAgain 

TargetPlatform Again  is  a  shortened  version  of  TargetPlatform  that  uses  a  set  of 
platform  position  propagation  parameters,  ChangeInX,  ChangelnY,  and  ChangeInZ  to 
propagate  the  platform  position  forward  in  time,  rather  than  recomputing  position  from 
latitude  and  longitude. 

Inputs 


struct  Aircraft  &ABLPlatf orm  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of 
the  Preprocessor. 

double  ThetaGInRad  This  is  the  angle  at  which  the  Earth’s  Greenwich 
Meridian  is  currently  at  with  respect  to  the  ECI  frame,  where  the  referent  angle  is 
the  Vernal  Equinox.  This  angle  should  be  in  radians. 

double  JUlianDate  This  is  the  modified  Julian  Date  (The  Julian  Date  - 
2440000)  that  needs  to  be  propagated  to.  This  is  the  actual  time  at  which  the  user 
wishes  to  find  the  position  of  the  satellite. 
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double  ChangeZnX  This  is  the  ECEF  X  propagation  distance  used  to 
propagate  the  platform  position  forward  in  time. 

double  ChangelnY  This  is  the  ECEF  Y  propagation  distance  used  to 
propagate  the  platform  position  forward  in  time. 

double  ChangeInZ  This  is  the  ECEF  Z  propagation  distance  used  to 
propagate  the  platform  position  forward  in  time. 

Outputs 

double  ftPlatformECIRhoX  The  current  ECI  X  position  vector  of  the 
position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
latitude  and  longitude  given  in  the  Aircraft  structure  input. 

double  &PlatfonnECIRboY  The  current  ECI  Y  position  vector  of  the 
position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
latitude  and  longitude  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoZ  The  current  ECI  Z  position  vector  of  the 
position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
latitude  and  longitude  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoXDot  The  current  ECI  X  velocity  vector  of 
the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECEF  velocities  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoYDot  The  current  ECI  Y  velocity  vector  of 
the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECEF  velocities  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoZDot  The  current  ECI  Z  velocity  vector  of  the 
velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from  the 
ECEF  velocities  given  in  the  Aircraft  structure  input. 

double  &Plat£onnECIRhoXDotDot  The  current  ECI  X  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  only.  It  is  assumed  that  the 
aircraft  itself  is  maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnECIRhoYDotDot  The  current  ECI  Y  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  only.  It  is  assumed  that  the 
aircraft  itself  is  maintaining  straight  and  level  flight  at  constant  velocity. 
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double  &Plat£onnECIRhoZI>otDot  The  current  ECI  Z  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  only.  It  is  assumed  that  the 
aircraft  itself  is  maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnRENRhoR  The  current  REN  R  (Radial)  position  vector 
of  the  position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  ECI  position  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoE  The  current  REN  E  (East)  position  vector  of 
the  position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived  from 
the  ECI  position  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoN  The  current  REN  N  (North)  position  vector 
of  the  position  of  the  platform  with  respect  to  the  center  of  the  Earth,  as  derived 
from  the  ECI  position  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoRDot  The  current  REN  R  (Radial)  velocity 
vector  of  the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  ECI  velocity  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoEDot  The  current  REN  E  (East)  velocity 
vector  of  the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  ECI  velocity  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoNDot  The  current  REN  N  (North)  velocity 
vector  of  the  velocity  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  ECI  velocity  vector,  rotated  into  the  REN  frame. 

double  &Plat£onnRENRhoRDotDot  The  current  REN  R  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  derived  in  the  ECI  frame 
and  rotated  into  the  REN  frame.  It  is  assumed  that  the  aircraft  itself  is 
maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnRENRhoEDotDot  The  current  REN  E  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  derived  in  the  ECI  frame 
and  rotated  into  the  REN  frame.  It  is  assumed  that  the  aircraft  itself  is 
maintaining  straight  and  level  flight  at  constant  velocity. 

double  &Plat£onnRENRhoNDotDot  The  current  REN  N  acceleration 
vector  of  the  acceleration  of  the  platform  with  respect  to  the  center  of  the  Earth,  as 
derived  from  the  centripetal  and  Coriolis  accelerations  derived  in  the  ECI  frame 
and  rotated  into  the  REN  frame.  It  is  assumed  that  the  aircraft  itself  is 
maintaining  straight  and  level  flight  at  constant  velocity. 
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double  &ECXtoRENMatrixll  This  an  element  (row  1,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrixl2  This  an  element  (row  1,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrixl3  This  an  element  (row  1,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix21  This  an  element  (row  2,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix22  This  an  element  (row  2,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix23  This  an  element  (row  2,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECZtoRENMatrix31  This  an  element  (row  3,  column  1)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrix32  This  an  element  (row  3,  column  2)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

double  &ECItoRENMatrlx33  This  an  element  (row  3,  column  3)  of  the 
matrix  used  to  transform  a  vector  from  the  ECI  coordinate  frame  to  the  REN 
coordinate  frame. 

ErrorStructure  &ErrorList  This  is  the  error-handling  structure 
that  is  used  as  both  an  input  (to  see  if  errors  have  occurred)  and  an  output  (to  list 
any  errors  occurring  in  this  module). 
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C.6.5  The  TargetSatellite.h  Header  File 


#ifndef  ProcessSatelliteH 
tdefine  ProcessSatelliteH 

/★******************★***★*****★********************★**★*****★*********★*★★*★★/ 
/*  MODULE  NAME:  ProcessSatellite . h  */ 

/*  AUTHOR:  Captain  David  Vloedman  */ 

/*  DATE  CREATED:  14  January,  1999  */ 

/*  */ 

/*  PURPOSE:  This  module  supports  the  meat  of  the  Main  Processor  and  */ 

/*  is  used  to  evaluate  the  error  angle  and  the  displacement*/ 

/*  angle  between  the  laser  position  vector  in  the  REN  frame*/ 

/*  and  the  satellite  position  vector  in  the  same  frame.  It*/ 

/*  uses  this  angle  and  its  rate  of  change  to  determine  when*/ 

/*  and  if  the  satellite  will  intersect  the  path  of  the  */ 

/*  laser.  */ 

/*  */ 

/*  COMPILER:  Borland  C++  BuilderS  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 


/****************************************************************************/ 

/*****★****************★******★**★/ 

/*  C++BUILDER-SPECIFIC  LIBRARIES  */ 

/**★***★**********★**★*********★*★/ 

#include  <vcl.h> 

#pragma  hdrstop 

#pragma  package ( smar t_ini t ) 

/***★*****★***********************/ 

/*  USER-BUILT  LIBRARIES  */ 

/****************★★*****★***★*****/ 

#include  ''  TimeModules  . h '' 

# include  "TLEInput .h" 

#include  "LaserConstants .h" 

#include  " Satellite. h" 

#include  " Aircraft . h" 

#include  "ErrorStructure .h” 

#include  "EvaluateEphemerisModules .h" 

#include  "SGP4SupportModules .h” 

#include  "FindDisplacementAngleModules .h” 

#include  “TargetSatellite.h" 
tinclude  "TargetPlatform.h" 

# include  "TargetLaser .h“ 

/*************.***★***********★****/ 

/*  C  STANDARD  LIBRARIES  */ 

/**************************★**★★**/ 

#include  <stdio.h> 

#include  <stdlib.h> 
iinclude  <string.h> 

#include  <iostream.h> 

#include  <conio.h> 

#include  <math.h> 

/************************************************** **★**★*******★************/ 
/****************★******  FUCTIONS  **************★**★***********/ 

/*★******★****************************************★*****★********★*****★*****/ 

/**********★*************************************★*************************** ^ 


/* 

FUNCTION  NAME: 

ProcessSatellite 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

January  13,  1999 

*/ 

/* 

*/ 

/* 

PURPOSE : 

This  module  supports  the  meat  of  theMain  Processor  and 

*/ 
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/*  is  used  to  evaluate  the  error  angle  and  the  displacement*/ 

/*  angle  between  the  laser  position  vector  in  the  REN  frame*/ 


/*  and  the  satellite  position  vector  in  the  same  frame.  It*/ 
/*  uses  this  angle  and  its  rate  of  change  to  determine  when*/ 
/*  and  if  the  satellite  will  intersect  the  path  of  the  */ 
/*  laser.  */ 
/*  */ 
/*  */ 
/*  COMPILER:  Borland  C++  Builder 3  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/**★****★******★**★***★****★***★**************★********★★*★******************/ 
void  ProcessSatellite (struct  Aircraft  ScPlatform, 

struct  Satellite  &Sat, 

int  ReferenceHour , 

int  ReferenceMinute, 

double  ReferenceSecond, 

double  RefModJulianDate, 

double  SecondsFromVertex, 

double  Interpolationincrement, 

double  ScThetaGInRad, 

double  JulianDate, 

double  LazeDuration, 

double  LaserAzimuthInDegrees , 

double  LaserAzimuthDot , 

double  LaserAzimuthDotDot , 

double  LaserElevationInDegrees , 

double  LaserElevationDot , 

double  LaserElevationDotDot , 

double  SatPositionErrorInMeters , 

double  PlatformPositionErrorInMeters , 

double  MissilePositionErrorInMeters, 

double  RangeToMissileInKilometers , 

double  OtherErrorAngleInDeg, 

double  ScRangelnKilometers , 

double  ScErrorAnglelnRadians , 

double  ScSeparationAngle, 

double  ScSepAngleDot , 

double  ScSepAngleDotDot , 

int  Sclntersection, 

int  ^Interpolation, 

double  ScTimeToIntersect, 

double  &ClosestApproachInDegrees , 

Errors tructure  ScErrorList)  ; 


/**★*****★****★***********************************★*************************★/ 
/*  FUNCTION  NAME:  InterpolateVertex  */ 

/*  AUTHOR:  Captain  David  Vloedman  */ 

/*  DATE  CREATED:  January  13,  1999  */ 

/*  */ 

/*  PURPOSE:  This  module  supports  the  meat  of  the  Main  Processor  and  */ 

/*  is  used  to  evaluate  the  error  angle  and  the  displacement*/ 

/*  angle  between  the  laser  position  vector  in  the  REN  frame*/ 

/*  and  the  satellite  position  vector  in  the  same  frame  */ 

/*  during  the  relatively  short  time  of  estimated  closest  */ 

/*  approach  of  the  two  vectors.  The  smaller  the  inter-  */ 

/*  polation  increment,  the  more  accurate  the  estimate,  and  */ 

/*  the  longer  the  processing  time.  */ 

/*  */ 

/*  COMPILER:  Borland  C++  Builder!  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 
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/★*********★*****************★**************★**★********★*★*****★*★***★★*****/ 
void  InterpolateVertex (struct  Aircraft  ScPlatform, 

struct  Satellite  &Sat, 
int  Ref erenceHour , 

int  Ref erenceMinute, 

double  Ref erenceSecond, 
double  RefModJulianDate, 
double  JulianDate, 
double  LazeDuration, 
double  LaserAzimuthInDegrees , 
double  LaserAzimuthDot , 
double  LaserAzimuthDotDot , 
double  LaserElevationInDegrees , 
double  LaserElevationDot , 
double  LaserElevationDotDot, 
double  ErrorAngleInRadians, 
double  Seconds FromVertex, 
double  Interpolationincrement , 
double  ScTimeToIntersect , 
double  &ClosestApproachInDegrees , 

Error  Structure  ScErrorList)  ; 


/*********★★**********★*********************★★************★*********★********/ 
/*  FUNCTION  NAME:  TargetPlatf orrnAgain  */ 

/*  AUTHOR:  Captain  David  Vloedman  */ 

/*  DATE  CREATED:  January  24, 1998  */ 

/*  */ 

/*  PURPOSE:  This  function  will  take  the  position  of  the  aircraft  and*/ 

/*  position, velocity  and  acceleration  in  the  REN  frame  of  */ 

/*  the  Airborn  lager  platform.  This  is  very  similar  to  */ 

/*  "TargetPlatform" ,  but  uses  slightly  different  input  */ 

/*  parameters.  */ 

/*  */ 

/*  COMPILER:  Borland  C++  Builder 3  Standard  version  */ 

/*  This  compiler  should  be  used  to  compile  and  link.  */ 

/*  */ 


/★***★****★*★**★*******★*★****************★*★*★*************★********★****★**/ 
void  TargetPlatf orrnAgain (struct  Aircraft  ^Platform, 

double  &ThetaGInRad, 
double  JulianDate, 
double  ChangeInX, 
double  Change InY, 
double  ChangeInZ, 
double  ScPlatformECIRhoX, 
double  ScPlatformECIRhoY, 
double  &PlatformECIRhoZ, 
double  &PlatformECIRhoXDot, 
double  ScPlatformECIRhoYDot , 
double  ScPlatf ormECIRhoZDot , 
double  &PlatformECIRhoXDotDot , 
double  &PlatformECIRhoYDotDot, 
double  ficPlatformECIRhoZDotDot , 
double  ScPlatformRENRhoR, 
double  &Platf ormRENRhoE, 
double  &PlatformRENRhoN, 
double  &PlatformRENRhoRDot, 
double  &PlatformRENRhoEDot, 
double  ScPlatformRENRhoNDot, 
double  &PlatformRENRhoRDotDot , 
double  &PlatformRENRhoEDotDot , 
double  ScPlatformRENRhoNDotDot , 
double  ficECItoRENMatrixll, 


193 


double  &ECItoRENMatrixl2, 
double  &ECItoRENMatrixl3 , 
double  &ECItoRENMatrix21, 
double  ScECItoRENMatrix22, 
double  &ECItoRENMatrix23 , 
double  &ECItoRENMatrix31, 
double  &ECItoRENMatrix32, 
double  &ECItoRENMatrix33, 
ErrorStructure  &ErrorList) ; 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


FUNCTION  NAME: 
AUTHOR: 

DATE  CREATED: 

PURPOSE : 


COMPILER: 


FindDisplacementAnglesAgain 
Captain  David  Vloedman 
January  23,  1999 

This  function  will  take  satellite  and  platform  data  and 
willuse  it  to  find  the  error  angle  and  the  displacement 
angle  between  the  laser  position  vector  in  the  REN  frame 
and  the  satellite  position  vector  in  the  same  frame. 
NOTICE  THAT  THIS  IS  NOT  "FindDisplacementAngles ” ,  BUT 
"FindDisplacementAnglesAgain" .  IT  IS  ONLY  SLIGHTLY 
DIFFERENT  THAN  THE  OTHER,  INCORPORATING  THE  THREE  INPUT 
PARAMETERS  ChangeInX,  ChangelnY  AND  ChangeInZ  WHICH 
DESCRIBES  A  SLIGHT  POSITION  CHANGE  IN  THE  ECEF  FRAME. 

Borland  C++  Builder3  Standard  version 

This  compiler  should  be  used  to  compile  and  link. 


V 

V 

V 

V 

V 

V 

V 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


/★*********************★***********★★** 
void  FindDisplacementAnglesAgain ( struct 

struct 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 


r*************************************/ 

Aircraft  ScPlatform, 

Satellite  &Sat, 

ScThetaGInRad, 

JulianDate, 

ChangeInX, 

ChangelnY, 

ChangeInZ, 

LaserAzimuthInDegrees , 

LaserAz imuthDot , 

LaserAz imuthDotDot , 
LaserElevationInDegrees , 
LaserElevationDot , 

LaserElevationDotDot , 
&PlatformSatRENRhoR, 

ScPlatf  ormSatRENRhoE , 
&PlatformSatRENRhoN, 

&  P 1 a t  f o rmS a t RENRhoRDo  t , 

&Platf ormSatRENRhoEDot , 

ScPlatf  ormSatRENRhoNDot , 

ScPlatf  ormSatRENRhoRDotDot , 

ScPlatf  ormSatRENRhoEDotDot , 
&PlatformSatRENRhoNDotDot, 
ficLas  erRENRhoR , 

ScLas  erRENRhoE , 

ScLaserRENRhoN, 

ScLaser  RENRhoRDo  t , 

&LaserRENRhoEDot , 

ScLas  erRENRhoNDot , 

ScLaserRENRhoRDotDot , 
ScLaserRENRhoEDotDot , 

ScLas  erRENRhoNDotDot , 
ScRangeToSatInKilometers , 
ScErrorAngleInRadians , 
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double  &Separatio]iAngle, 
double  ficSepAngleDot , 
double  &SepAngleDotDot, 
ErrorStructure  ScErrorList) 


#endif 
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C.7  The  ABLPA  Main  Processor 

The  Main  Processor  is  the  final  culmination  of  all  of  the  software  discussed  previously. 
The  task  of  the  Main  Processor  is  to  take  the  output  file  containing  all  active  satellites  in 
view  of  the  platform,  and  create  two  output  files.  The  first  output  file  will  contain  all  of 
the  satellites  that  are  forecast  to  be  intersected  by  the  laser  during  the  laze  duration.  The 
Processor  also  creates  an  output  file  containing  the  satellites  that  pass  closely  enough  to 
the  laser  path  to  be  “interpolated”,  or  analyzed,  but  may  or  may  not  actually  intersect  the 
laser.  This  second  “close-approach”  file  is  used  more  for  testing  and  verification  than 
operational  use.  Statistically,  more  often  than  not  the  Intersection  File  will  be  empty  after 


Figure  C.8.  The  Graphical  Interface  Developed  to  Run  the  Main 

Processor 
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a  full  Main  Processor  run-through,  because  the  chances  of  “hitting”  a  satellite  (even  with 
a  theoretical  error-angle)  is  slim.  This  close  approach  file  can  be  used  to  verify  the 
successful  run  and  processing  of  the  Main  Processor.  Both  output  files  have  exactly  the 
same  format  as  the  main  TLE  file,  except  they  have  fewer  (or  no)  satellites  within  them. 
This  processor  can  be  run  independently,  by  a  calling  module  made  by  the  user,  or  by 
using  the  GUI  developed  to  run  and  test  the  processor  during  project  development.  This 
graphical  interface  is  illustrated  in  Figure  C.8. 

C.7.1  PAMainProcessor 

The  Main  Processor  calls  the  ReadTLEFile  module  to  accomplish  loading  of  all 
of  the  satellites  in  the  input  file,  and  then  makes  repeated  calls  to  ProcessSatellite  to 
analyze  each  satellite  in  turn.  It  can  be  seen  that  the  format  of  the  Main  Processor  is  very 
similar  to  the  Preprocessor,  using  input  and  output  TLE  files  to  accomplish  most  of  the 
satellite  information  transfer. 


C.7.2  Inputs 

charlnFileName  [MAXNAMELEN6TH]  This  parameter  holds  the  name  of 
the  Two  Line  Element  Set  that  holds  the  satellites  to  be  evaluated. 

char  OutFlleName  [lUtXNAMELENGTH]  Holds  the  name  of  the  file  to 
which  the  intersected  satellites’  Two-Line  Element  set  information  is  routed  to. 
This  file  holds  all  of  the  satellites  that  have  been  judged  by  the  Processor  to  be 
intersected  by  the  laser  during  the  laser  firing  time. 

char  Closest ApproachFileNaiae  [MAXNAMELENGTH]  Holds  the  name 
of  the  file  to  which  the  close-approach  satellites’  Two-Line  Element  set 
information  is  routed  to.  This  file  holds  all  of  the  satellites  that  have  been  judged 
by  the  Processor  to  be  close  enough  to  the  laser  beam  that  interpolation  is 
required. 
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struct  Aircraft  &ABLPlat£onn  ABLPlatform  is  a  structure  of  type 
“Aircraft”  that  holds  all  of  the  information  about  the  position  of  the  aircraft  at  the 
time  of  execution  of  the  Processor. 

int  ReferenceHour  Reference  hour  Refers  to  the  Reference  angle  of  9g 
(The  angle  between  the  Greenwich  meridian  and  the  Vernal  Equinox).  This 
angles  is  given  in  hours,  minutes  and  seconds  as  opposed  to  degrees  or  radians. 
This  parameter  holds  the  hours  portion  of  6g. 

int  ReferenceMinute  The  minutes  portion  of  6g. 

double  ReferenceSecond  The  seconds  portion  of  0g. 

double  RefModJulianDate  This  parameter  holds  the  Modified  Julian 
Date  at  which  the  reference  angle,  0g,  was  taken.  This  allows  0g  to  be  propagated 
forward  to  the  present  moment. 

int  CalcYear  The  current  year. 

int  CalcMonth  The  current  month  (1-12). 

int  CalcDay  The  current  day  (1-31). 

int  CalcHour  The  current  hour  (1-24). 

int  CalcMinute  The  current  minute  (1-60). 

doxible  CalcSecond  The  current  second.  This  is  the  only  part  of  the 
current  time  that  can  be  given  as  a  non-integer.  This  field  should  be  accurate  to 
at  least  three  decimal  places. 

double  LazeDuration  The  expected  amount  of  time  that  the  lazer  will  be 
“on”,  or  illuminating  its  target.  It  is  estimated  that  this  value  should  never 
operationally  exceed  thirty  seconds. 

double  Laser AzimuthlnDegrees  The  current  azimuth  of  the  laser 

turret  in  degrees. 

do\ible  LaserAzimuthDot  The  current  rate  of  change  of  the  azimuth  of  the 
laser  turret  in  degrees  per  second. 

double  LaserAzimuthDotDot  The  current  acceleration  of  the  azimuth  of 
the  laser  turret  in  degrees  per  second. 

double  LaserElevationlnDegrees  The  current  elevation  of  the  laser 
turret  in  degrees. 
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double  LaserElevationDot  The  current  rate  of  change  of  the  elevation 
of  the  laser  turret  in  degrees  per  second. 

double  LaserAzimuthDotDot  The  current  acceleration  of  the  azimuth  of 
the  laser  turret  in  degrees  per  second. 

double  LaserElevationDotDot  The  current  acceleration  of  the  elevation 
of  the  laser  turret  in  degrees  per  second. 

double  SatPositionErrorlnMeters  The  radius  of  the  “sphere”  inside 
which  the  satellite  is  known  to  reside  (in  meters)  throughout  the  forecast  period 
(around  10  to  30  seconds).  For  SGP4,  this  may  be  as  high  as  around  10  km 
(10000  m). 

double  PlatformPositionErrorInMeters  The  radius  of  the  “sphere” 
inside  which  the  platform  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  For  a  747  on  autopilot  with  GPS  tracking,  a 
rough  estimate  might  be  50  meters. 

double  MissilePositionErrorInNeters  The  radius  of  the  “sphere” 
inside  which  the  missile  is  known  to  reside  (in  meters)  throughout  the  forecast 
period  (around  10  to  30  seconds).  This  may  just  be  an  educated  guess.  It  is 
difficult  to  now  the  behavior  of  the  missile  based  on  initial  conditions,  and  this 
parameter  will  have  to  be  given  some  thought. 

double  RangeToMissileZnKilometers  The  range  from  the  platform  to 
the  missile. 

double  OtherErrorAnglelnDeg  This  is  a  “catch-all”  parameter,  to  be 
used  if,  in  the  future,  there  are  other  error  angles  that  crop  up  that  have  not  already 
been  accounted  for. 

double  SecondsFromVertex  This  input  parameter  describes  the  number 
of  seconds  before  the  forecast  intercept  time  the  the  user  desires  to  analyze  via 
interpolation.  For  a  better  explanation  on  interpolation,  see  Chapter  El.  The 
author  recommends  this  time  interval  be  around  2.0  seconds. 

double  Interpolationlncrement  The  amount  of  time  that  transpires 
between  samplings  when  interpolating  the  vertex.  For  a  better  explanation  on 
interpolation,  see  Chapter  III.  The  author  recommends  this  time  interval  be 
around  0. 1  seconds. 
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C.7.3  Outputs 


int  &IiiFileLength  This  parameter  tells  the  user  how  many 

elements  were  read  in  from  the  file  specified  by  the  input  parameter 
“InFileName[MAXNAMELENGTH]”.  This  is  the  total  number  of  satellites  that 
will  be  evaluated  during  the  run  of  the  Processor. 

int  &OutFileLength  This  parameter  tells  the  user  how  many 

elements  were  written  to  the  file  specified  by  the  input  parameter 
“OutFileName[MAXNAMELENGTH]”.  This  is  the  total  number  of  satellites 
that  were  judged  to  be  “intersected”  of  the  laser  between  the  time  of  the  start  of 
lazing  and  the  end  of  the  laze. 

int  &CloseApproachFileLength  This  parameter  tells  the  user  how 
many  elements  were  written  to  the  file  specified  by  the  input  parameter 
“CloseApproachFileName[MAXNAMELENGTH]”.  This  should  always  be 
bigger  than  or  equal  to  OutFileLength. 

double  &Theta6InDegrees  This  is  the  instantaneous  angle  between  the 
Greenwich  meridian  and  the  Vernal  Eqinox  at  the  moment  of  execution  of  the 
Processor. 

ErrorStmicture  &ErrorList  This  parameter  is  both  an  input  and 
output  parameter.  Each  module  uses  it  to  assess  whether  a  fatal  error  has 
occurred  somewhere  else  in  the  program,  and  uses  it  to  record  errors  which  may 
be  important  to  the  user. 
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C.7.4  The  PAMainProcessonh  Header  File 


#ifndef  PAMainProcessorH 
#define  PAMainProcessorH 

/*****★****************★**★*★****★********★**★*******************************/ 


/*  MODULE  NAME:  PAMainProcessor . h  */ 
/*  AUTHOR:  Captain  David  Vloedman  */ 
/*  DATE  CREATED:  January  10, 1998  */ 
/*  */ 
/*  PURPOSE:  This  module  is  the  model  of  the  Airborne  Laser  */ 
/*  Predictive  Avoidance  Processor  which  may  be  used  to  */ 
/*  determine  whether  or  not  a  given  Laser  trajectory  will  */ 
/*  intersect  with  any  of  a  list  of  satellites  fed  to  it.  */ 
/*  */ 
/*  COMPILER:  Borland  C++  Builder3  Standard  version  */ 
/*  This  compiler  should  be  used  to  compile  and  link.  */ 
/*  */ 


/****************************************************************************/ 

/*********************************/ 

/*  C++BUILDER-SPECIFIC  LIBRARIES  */ 

/*********************************/ 

#include  <vcl.h> 

tpragma  hdrstop 

#pragma  package (smart_init) 

/********★******************★*****/ 

/*  USER-BUILT  LIBRARIES  */ 

/****★*★★***********************★*/ 

#include  "TimeModules .h" 

# include  “TLEInput .h" 

#include  "LaserConstants .h” 

#include  "Satellite .h" 

#include  "Aircraft.h" 

# include  ” Errors true ture .h" 

#include  "EvaluateEphemerisModules .h" 

#include  "PAMainProcessor .h" 

# include  "SGP4SupportModules .h" 

#include  "FindDisplacementAngleModules .h" 

#include  "TargetSatellite.h" 

#include  "TargetPlatform.h" 

# include  "TargetLaser .h” 

#include  ” ProcessSatellite .h" 

/*********************************/ 

/*  C  STANDARD  LIBRARIES  */ 

/********************★************/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <string.h> 

#include  <iostream.h> 

#include  <conio.h> 

# include  <math.h> 

/*★**************************************************★*★*****★*★★************/ 
/***************★*******  FUCTIONS  ****************★************/ 

/********★**★*************************************★***********★**************/ 

/************★**★★★★*★**★***************★*******★*****★******★***************/ 


/* 

FUNCTION  NAME: 

PAMainProcessor 

*/ 

/* 

AUTHOR: 

Captain  David  Vloedman 

*/ 

/* 

DATE  CREATED: 

January  15,  1998 

*/ 

/* 

*/ 
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/*  PURPOSE: 
/* 

/* 

/* 

/* 

/*  INPUTS: 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


This  procedure  will  read  in  an  input  file  of  Two  Line  */ 
Element  (TLE)  sets  and  perform  an  analysis  to  determine  */ 
whether  or  not  satellites  will  be  intercepted  by  the  */ 
path  of  the  airborne  platform  laser.  */ 

*/ 

NAME:  DEFINITION:  */ 

InFileName  Holds  name  of  the  satellite  file*/ 

OutFileName  File  that  holds  the  sats  that  */ 

are  forecasted  by  the  software  */ 
to  be  intercepted  bt  the  laser.  */ 
Closes tApproachFileName  File  that  holds  the  sats  that  */ 

are  forecasted  by  the  software  */ 
to  be  close  to  the  laser.  These  */ 
are  not  necessarily  intersected.*/ 
ABLPlatform  Holds  all  information  about  ABL  */ 


Platform  position/disposition  */ 
ReferenceHour  This  holds  the  value  of  Theta  G  */ 

at  RefModJulianDate.  The  angle  */ 
of  Theta  G  is  given  in  hours,  */ 
:<  minutes,  and  seconds  instead  of  */ 

degrees,  where  24  hrs  =  360  deg  */ 
ReferenceMinute  Holds  the  minutes  of  Theta  G  at  */ 

RefModJulianDate.  */ 

ReferenceSecond  Holds  the  seconds  of  Theta  G  at  */ 

RefModJulianDate.  */ 

RefModJulianDate  This  is  the  reference  date  when  */ 

an  actual  observation  of  the  */ 
true  value  of  theta  G  was  made.  */ 
CalcYear  Holds  the  current  calender  year  */ 

Calcmonth  Holds  the  Calender  month(l  -  12)*/ 

CalcDay  Holds  calender  day  */ 

CalcHour  Holds  the  calender  hour  */ 

CalcMinute  Holds  the  calender  minute  */ 

CalcSecond  Holds  the  calender  second  */ 

LazeDuration  The  amount  of  time  for  which  the*/ 

laser  will  be  on.  This  is  */ 

To  determine  how  much  time  in  */ 
seconds  the  forecast  will  last.  */ 
LazerAzimuthInDegrees  Lazer  Azimuth  at  Laze  Start  time*/ 

in  Degrees  */ 

LazerAzimuthDot  The  rate  of  change  of  the  Az  */ 

in  Degrees /Sec.  */ 

LazerAzimuthDotDot  The  rate  of  change  of  the  rate  */ 

of  change  of  the  Azimuth  (Accel)*/ 
in  Degrees/Sec'"2  */ 

LazerElevationInDegrees  Lazer  Elevation  at  Laze  Start  */ 

in  Degrees  */ 

LazerElevationDot  The  rate  of  change  of  the  El  */ 

in  Degrees /Sec.  */ 

LazerElevationDotDot  The  rate  of  change  of  the  rate  */ 

of  change  of  the  Elevat.  (Accel)*/ 
in  Degrees /Sec^2  */ 

SatPositionErrorInMeters  Holds  the  radius  of  the  error  */ 

spheroid  that  describes  the  */ 

area  in  which  the  satellite  is  */ 

known  to  exist  (in  meters) .  */ 

PlatformPositionError .. .Holds  the  radius  of  the  error  */ 

spheroid  that  describes  the  */ 

area  in  which  the  platform  is  */ 
known  to  exist  (in  meters) .  */ 

MissilePositionError . . .  Holds  the  radius  of  the  error  */ 

spheroid  that  describes  the  */ 

area  in  which  the  missile  is  */ 
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/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/*  OUTPUTS: 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/*  COMPILER: 
/* 

/* 


known  to  exist  (in  meters) .  */ 

RangeToMissileInKilo , . .  The  Range  to  the  missile  (km)  */ 

OtherErrorAnglesInDeg  Holds  any  other  error  angles  */ 

(in  degrees)  that  may  be  a  */ 

significant  source  of  error.  */ 

This  should  usually  be  set  to  */ 

zero  (0.0)  float.  */ 

ThetaGInRadians  The  angle  between  the  Greenwich  */ 

Meridian  and  the  Vernal  Equinox  */ 
at  JulianDate.  */ 

*/ 

NAME:  DESCRIPTION:  */ 

InFileLength  The  total  number  of  satellites.  */ 

that  have  been  evaluated  in  the  */ 
InFile  */ 

OutFileLength  The  total  number  of  satellites  */ 


that  are  intersected  by  platform*/ 
and  have  been  put  in  the  out file*/ 
C loses tApproachFileLength  The  total  number  of  satellites*/ 


that  come  close  to  the  laser  */ 
and  have  been  put  in  the  */ 

closest  approach  file.  */ 

ErrorList  Errors  that  have  occured  */ 

*/ 

THE  FINAL  OUTPUT  IS  THE  ACTUAL  OUTFILE  ITSELF  WHICH  IS  */ 
WRITTEN  DIRECTLY  TO  DISK  SO  IT  CAN  BE  ACCESSED  BY  */ 

OTHER  SOFTWARE,  IF  NEEDED.  */ 

*/ 

Borland  C++  BuilderB  Standard  version  */ 

This  compiler  should  be  used  to  compile  and  link.  */ 

*/ 


PAMainProcessor  (char 
char 
char 
int 
int 
int 

struct 

int 

int 

double 

double 

int 

int 

int 

int 

int 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 

double 


InFileName[MAXNAMELENGTH] , 
OutFileName[MAXNAMELENGTH] , 
ClosestApproachFileName [MAXNAMELENGTH] , 
&InFileLength, 

ScOu  tF  i  1  eLeng  th , 

&Closes tApproachFileLength, 

Aircraft  &ABLPlatform, 

Ref erenceHour , 

Ref erenceMinute , 

ReferenceSecond, 

Re  f Mo  d Ju 1 i anDa t e , 

CalcYear , 

CalcMonth, 

CalcDay, 

CalcHour , 

CalcMinute, 

CalcSecond, 

LazeDuration, 

LaserAzimuthInDegrees , 

LaserAzimuthDot , 

LaserAzimuthDotDot , 
LaserElevationInDegrees , 
LaserElevationDot , 

LaserElevationDotDot , 

SatPosi tionErrorInMeters , 
PlatformPositionErrorInMeters , 
MissilePosi tionErrorInMeters , 
RangeToMissileInKilometers , 
OtherErrorAngleInDeg , 

SecondsFromVertex, 
Interpolationincrement , 
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double  ScThetaGInDegrees, 
ErrorStructure  ScErrorList) 

#endif 
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